Capas de ingeniería del Software. Rosendo Antonio Manuel Ingeniería en Sistemas Computacionales.
Ingeniería en Sistemas Computacionales
-
Upload
carmen-flores -
Category
Documents
-
view
719 -
download
8
Transcript of Ingeniería en Sistemas Computacionales
Ingeniería en Sistemas Computacionales
Tópicos Selectos De Programación
Unidad VI / Programación de puertos e interrupciones
Noviembre 2009
6.1 Conceptos fundamentales de interrupciones y puertos.
Concepto de interrupción:
Ya que un procesador no puede procesar simultáneamente varios trozos de información (procesa un trozo de información por vez), un programa que está siendo ejecutado puede, gracias al pedido de interrupción, ser momentáneamente suspendido mientras se produce una interrupción.
El programa interrumpido puede continuar ejecutándose luego. Existen 256 direcciones de interrupción diferentes.
Una interrupción se convierte en una interrupción de hardware cuando es solicitada por uno de los componentes de hardware del equipo. En efecto, existen varios periféricos en un equipo. Estos periféricos necesitan generalmente utilizar los recursos del sistema aunque sólo sea para comunicarse con el sistema mismo.
Cuando un periférico desea acceder a un recurso, envía un pedido de interrupción al procesador para llamar su atención. Los periféricos cuentan con un número de interrupción que se denomina IRQ (Peticiones de Interrupción. Es como si cada periférico tirara de un “hilo” que está atado a una campana para señalarle al equipo que desea que le preste atención.
Este “hilo” es, de hecho, una línea física que conecta cada ranura de expansión así como cada interfaz E/S a la placa madre. Para una ranura ISA de 8 bits, por ejemplo, hay 8 líneas IRQ que unen ranuras ISA de 8 bits a la placa madre (IRQ0 a IRQ7). Estos IRQ están controlados por un “controlador de interrupción” que se encarga de “cederle la palabra” al IRQ que posee la mayor prioridad.
{text:bookmark-start} {text:bookmark-end}
Los *métodos interrupt* que se manejan en Java. Son 3
Interrupt()
Interrupted()
isInterrupted()
Interrupciones Sintaxis
Primero el método checkAccess de este thread es invocado, lo cual puede causar una Security Exception.
Si este thread es bloqueado en un selector, entonces el estado del thread de intrrupt será fijado, y retornara inmediatamente de la operación de selección, posiblemente con un valor diferente a cero, justo como si el método del selector wakeup hubiera sido invocado.
Si ninguna de las condiciones pasadas se cumple, entonces el estado en interrupt del thread será fijado (activado).
Interrupted (interrumpido)
Sintaxis Public static boolean interrupted ()
Hace una prueba si el thread actual a sido interrumpido. El estado de interrupción del thread es deshecho por este método. En otras palabras, si este método se llamara dos veces, la segunda vez devolvería un valor falso (al menos que el thread actual sea interrumpido de nuevo, después de que la primera llamada haya terminado su interrupción y antes de que la segunda empiece).
Returns: Verdadero si el thread actual a sido interrumpido, falso de lo contrario
6.2 Puerto serial y sus variantes
{draw:frame} Puerto serial, puerto COM, puerto de comunicaciones y puerto RS-232(“Recomended Standard-232”), hacen referencia al mismo puerto.
Es un conector que permite la transmisión de datos entre un dispositivo externo (periférico), con la computadora; por ello es denominado puerto.
Todos los sistemas operativos de los ordenadores que están en uso hoy en día, soportan los puertos serie, ya que han estado en funcionamiento durante décadas. Los puertos paralelos son una invención más reciente y son mucho más rápidos que los puertos serie. Los puertos USB solo tienen unos pocos años de antigüedad, y con el tiempo seguramente reemplazaran a los puertos serie y paralelo en los próximos años.
El nombre de serie viene por el hecho de que un puerto serie serializa los datos. Esto significa que coge un byte de datos y trasmite los 8 bits que contiene el byte uno a la vez. La ventaja es que los puertos serie solo necesitan un hilo para transmitir los 8 bits, mientras que los paralelo necesitan 8. La desventaja es que lleva 8 veces más de tiempo que si tuviera 8 hilos. Los puertos serie bajan el coste de los cables y hacen que sean mas pequeños.
Antes de cada byte de datos, los puertos serie envían un bit de comienzo, el cual es un único bit con un valor de 0. Después de cada byte de datos, envía un bit de parada para señalar que el byte esta completo. También envía un bit de paridad.
Terminales eléctricas del puerto serial. El puerto serial cuenta con 9 contactos tipo pin, se muestran las líneas eléctricas y su descripción básica.
Variantes físicas del puerto serial. Los puertos serie, también llamados puertos de comunicación (COM), son bidireccionales. La comunicación bidireccional permite a cada dispositivo recibir datos a la vez que los transmite. Los dispositivos serie usan pines diferentes para el recibir y enviar datos, usar los mismos pines significaría que la comunicación estaría limitada a half-duplex, y que la información viajaría en una sola dirección a la vez. Usar pines diferentes permite una comunicación full-dúplex, y puede viajar en ambos sentidos.
6.3 Puerto paralelo y sus variantes
Definición: Un puerto es el lugar donde el CPU se comunica con otros dispositivos, existen de varios tipos, hay puertos de entrada, de salida y ambos. Además estos pueden ser seriales o paralelos.
Puertos de salida: Son todos aquellos por donde el CPU envía datos a otros dispositivos, por ejemplo están la salida de video y de sonido.
Nosotros vamos a hablar acerca de los puertos que se encuentran fuera del gabinete, hablaremos de los puertos de teclado, mouse, impresoras, etc. La computadora por si misma no sería capaz de realizar operaciones útiles para nosotros si no podemos comunicarnos con ella, necesita dispositivos periféricos por donde pueda darnos mensajes y nosotros podamos enviarle órdenes.
Ahora bien, existen infinidad de dispositivos que sirven de extensión a la computadora, muchos son para fines muy específicos y no se pueden abarcar, entre los dispositivos que son de uso común se encuentra la impresora, el teclado, el mouse y el monitor.
Puerto serial: El puerto serial es aquel que envía y recibe los datos BIT por BIT, entre los puertos seriales se puede mencionar el puerto de teclado, o el puerto del MODEM.
Puerto paralelo: Este tipo de puerto transmite la información byte por byte, o sea que transmite ocho bits al mismo tiempo, de forma paralela. Un puerto paralelo por excelencia pues es el puerto para impresora
Se puede observar que un puerto de entrada puede ser paralelo o serial, lo mismo que un puerto de entrada o de entrada / salida.
A cada puerto la BIOS le asigna una dirección de memoria para que pueda trabajar, dependiendo de que clase de puerto sea se le asigna un determinado espacio exclusivo para él. Por medio de estas localidades de memoria el sistema puede enviarles o recibir información, es una especie de memoria de intercambio para la transmisión de dados de un lugar a otro. A esto se le llama espacio de localidades de memoria y se realiza dentro del primer kilo bite de la memoria principal. Existen otras asignaciones de memoria en otras capas superiores de memoria pero estas son hechas por el sistema operativo y por los demás programas, pero estas asignaciones son para fines específicos de los demás programas.
Los puertos no solo se limitan a recibir la información, o enviarla, según sea el caso. El puerto provee la corriente eléctrica necesaria para el funcionamiento del dispositivo y revisa el estado de este.
6.4 Interrupciones que intervienen en cada punto
Una interrupción es un mecanismo que permite ejecutar un bloque de instrucciones interrumpiendo la ejecución de un programa, y luego restablecer la ejecución del mismo sin afectarlodirectamente. De este modo un programa puede ser interrumpido temporalmente para atender alguna necesidad urgente del computador y luego continuar su ejecución como si nada hubiera pasado.
Generalmente se aplica para realizar tareas elementales asincrónicas en el computador tales como responder al teclado, escribir en la pantalla, leer y escribir archivos. Podemos considerar una tarea asincrónica como aquella que es solicitada sin previo aviso y aleatoriamente desde el punto de vista del computador. Tomemos el caso de la operación Ctrl-Alt-Supr. En Windows tiene el efecto de que aparece en pantalla una lista de los procesos y ventanas en ejecución en el computador. En cambio en el Sistema Operativo DOS cuando el usuario presiona simultáneamente dichas teclas el computador procede a reinicializarse, aunque pueda estar ocupado ejecutando un programa en ese instante. Vale decir fuerza obligadamente a que el computador se reinicialice. Ya sea en el sistema Windows o en DOS, el computador no está constantemente monitoreando el teclado para ver si el usuario ha solicitado un Ctrl-Alt-Del, ya que en ese caso consumiría mucho tiempo de proceso en ello y por ende la capacidad de proceso se vería significativamente afectada. La solución empleada es una interrupción.
Luego cada vez que el usuario presiona una tecla, la CPU es advertida a través de una señal especial de interrupción. Cuando la CPU advierte/recibe una señal de interrupción suspende temporalmente el proceso actual almacenando en memoria RAMun bloque con toda la información necesaria para restablecer posteriormente la ejecución del programa si es que procede. Enseguida la CPU determina qué elemento ha solicitado la interrupción y para cada caso existe un bloque de instrucciones que realiza la tarea correspondiente que es ejecutada a continuación. Terminada la ejecución se restablece el programa original en el mismo punto en que fue interrumpido usando para ello la información almacenada previamente.
Cada interrupción tiene asignada un número único. El PC está diseñado de manera que la interrupción tiene asignada 4 bytes de memoria RAM. La dirección de los cuatro bytes en la memoria corresponde al _número de la _interrupción multiplicado por 4. Por ejemplo la interrupción IRQ 5 tiene asignada 4 bytes en la dirección 0x00014 (0000:0014). El contenido de los 4 bytes de memoria RAM asignados a una interrupción contiene a su vez una dirección que es un puntero a un bloque de instrucciones de máquina que realiza el procedimiento correspondiente. De este modo al iniciar la ejecución de una interrupción de los cuatro bytes que tiene asignados se obtiene la dirección del bloque de instrucciones que efectivamente se ejecutan. Por ejemplo si en la dirección 0000:0014 estuviera almacenado el valor 0xFFF00, ello significa que en dicha dirección (ó (F000:FF00) se encuentra el bloque de instrucciones a ejecutar cuando la interrupción IRQ 5 sea requerida.
Esta forma de direccionamiento indirectopara las interrupciones brinda la flexibilidad necesaria para perfeccionar, modificar y extender el código de instrucciones correspondiente permitiendo mantener por ejemplo la compatibilidad de las distintas versiones de BIOS con las aplicaciones y equipos que usan las interrupciones.
Tipos de interrupciones
Existen tres tipos de interrupciones:
a) requeridas por hardware
Una lista de las interrupciones generadas por hardware es la siguiente
b) requerida por software para interactuar con periféricos
Los vectores de las interrupciones BIOS están ubicados a partir del vector 0x10H, vale decir inmediatamente a continuación de los vectores 0 a15 que son generados por hardware y que no son enmascarables. Cabe hacer notar que la arquitectura del PC está definida de tal manera que el primer Kilobyte del espacio de memoria está reservado para vectores de interrupciones, vale decir hay espacio para 256 interrupciones.
Las interrupciones BIOS más importantes son las siguientes
*6.5* Envió y recepción de datos
Cuando se escriben programas Java que se comunican a través de la red, se está programando en la capa de aplicación. Típicamente, no se necesita trabajar con las capas TCP y UDP — en su lugar se puede utilizar las clases del paquete java.net. Estas clases proporcionan comunicación de red independiente del sistema.
A través de las clases del paquete java.net, los programas Java puede utilizan TCP o UDP para comunicarse a través de Internet. Las clases URL, URL Connection, Socket, y Socket Server? Utilizan el TCP para comunicarse a través de la Red. Las clases ? Y Datagram Server? Utilizan UDP.
TCP proporciona un canal de comunicación fiable punto a punto, lo que utilizan para comunicarse las aplicaciones cliente-servidor en Internet. Las clases Socket y Server Socket del paquete java.net proporcionan un canal de comunicación independiente del sistema utilizando TCP, cada una de las cuales implementa el lado del cliente y el servidor respectivamente.
La clase Socket del paquete java.net es una implementación independiente de la plataforma de un cliente para un enlace de comunicación de dos vías entre un cliente y un servidor. La clase Socket se sitúa en la parte superior de una implementación dependiente de la plataforma, ocultando los detalles de los sistemas particulares a un programa Java. Utilizando la clase java.net.Socket en lugar de tratar con código nativo, los programas Java pueden comunicarse a través de la red de una forma independiente de la plataforma.
El entorno de desarrollo de Java incluye un paquete, java.io, que contiene un juego de canales de entrada y salida que los programas pueden utilizar para leer y escribir datos. Las clases Input Stream y Output Stream del paquete java.io son superclases abstractas que definen el comportamiento de los canales de I/O secuenciales de Java. java.io también incluye muchas subclases de Input Stream y Output Stream que implementan tipos específicos de canales de I/O.
Básicamente disponemos de dos tipos de servicio:
Servicio sin conexión, donde el emisor y el receptor intercambian paquetes de información sin establecer una conexión previa, donde tampoco disponemos de un control de secuencia ni control de errores. En este tipo de conexión operamos con Datagramas y el protocolo empleado es UDP.
Servicio orientado a conexión: Donde disponemos de un stream que nos asegura la entrega de la información de forma ordenada y fiable. Operamos con streams y el protocolo empleado es TCP
Java nos da soporte para:
getAddress() getAllByName(string) getByName(String) getHostAddress() getHostName() getLocalHost() hashCode() isMulticastAddress() toString()
Envío y recepción de datos a través de sockets:
El servidor crea un Socket, mediante Server Socket, le asigna una dirección y un puerto y acepta llamadas (accept). A partir de este momento el proceso queda bloqueado a la espera de una llamada. Cuando llega una llamada, el accept crea un nuevo socket para procesar dicha llamada. Es únicamente en ese momento cuando existe la conexión y durará hasta que se libere mediante close().
Los sockets tienen asociados un Stream de entrada y otro de salida a través de los cuales se leen y escriben los datos:
Para enviar datos se puede utilizar el Output Stream del socket, para enviar un flujo de bytes sin buffer. Pero también se puede crear un objeto de tipo stream de datos basado en el Output Stream.
_Socket socket = new Socket (“158.42.112.67″, 1056); _
_String linea; _
teclado_ = new Buffered Reader(new _Input Stream Reader?_(System.in)); _
escribir_ = new Print Writer(socket.getOutputStream(),true); _
do_ { _
linea_=teclado.readLine(); _
escribir.println_(linea); _
_} while (linea.compareTo(“#”)!=0); _
….
Para recibir datos se puede utilizar Input Stream o definir un nuevo objeto del mismo tipo más eficiente.
Ejemplo:
Buffered Reader leer;
String s;
leer=_new Buffered Reader( new Input Stream Reader (socketRecepcion.getInputStream() ) ); _
while_ (“#”.compareTo(s=leer.readLine()!=0) { _
System.out.println_(nombre+”: “+s); _
}
THREADS: En el programa se pueden implementar varios hilos de ejcución o threads. Podemos crear un servidor concurrente que ejecute el mismo código para cada cliente. Para ello podemos implementar un servidor para un solo cliente y dedicar un thread por cliente.
Implementando una nueva clase derivada de la clase Thread.
Creando una nueva clase que implemente el interface Runnable.
Import java.io.*;
Import java.net.*;
Class _Servidor Eco Tcp__ extends Thread { _
Socket s=null;
?_(Socket s) {this.s=s;} _
_Public void run() { _
_Try { Input Stream is=s.getInputStream(); _
Output Stream _os=s.getOutputStream(); _
While(_true) os.write(is.read()); _
} catch (IO Exception_ e) {__System.out.println(“Error en socket”);}} _
_Public static void main(String agrs[]) throws IO Exception , _Unknown Host Exception?_ { _
_Server Socket ss=new Server Socket(7); _
While(true) {
_e.start(); _
}
}
}
Existe otro tipo de socket, RAW SOCKET que no opera en el nivel de transporte y accede directamente al nivel de red. Este tipo de socket suele ser utilizado por aplicaciones con privilegios para la definición de protocolos de bajo nivel.
{text:bookmark-start} Puertos y Servicios
Cada servicio está asociado a un puerto. Un puerto es una dirección numérica a través de la cual se procesa el servicio. Sobre un sistema Unix, los servicios que proporciona ese sistema se indican en el fichero /etc/services, y algunos ejemplos son:
La primera columna indica el nombre del servicio. La segunda columna indica el puerto y el protocolo que está asociado al servicio. La tercera columna es un alias del servicio; por ejemplo, el servicio smtp, también conocido como mail, es la implementación del servicio de correo electrónico.
Las comunicaciones de información relacionada con Web tienen lugar a través del puerto 80 mediante protocolo TCP. Para emular esto en Java, usaremos la clase Socket. La fecha (daytime). Sin embargo, el servicio que coge la fecha y la hora del sistema, está ligado al puerto 13 utilizando el protocolo UDP. Un servidor que lo emule en Java usaría un objeto
6.1 Interrupciones.
Concepto de interrupción:
Ya que un procesador no puede procesar simultáneamente varios trozos de información (procesa un trozo de información por vez), un programa que está siendo ejecutado puede, gracias al pedido de interrupción, ser momentáneamente suspendido mientras se produce una interrupción.
El programa interrumpido puede continuar ejecutándose luego. Existen 256 direcciones de interrupción diferentes.
Una interrupción se convierte en una interrupción de hardware cuando es solicitada por uno de los componentes de hardware del equipo. En efecto, existen varios periféricos en un equipo. Estos periféricos necesitan generalmente utilizar los recursos del sistema aunque sólo sea para comunicarse con el sistema mismo.
Cuando un periférico desea acceder a un recurso, envía un pedido de interrupción al procesador para llamar su atención. Los periféricos cuentan con un número de interrupción que se denomina IRQ (Peticiones de Interrupción. Es como si cada periférico tirara de un “hilo” que está atado a una campana para señalarle al equipo que desea que le preste atención.
Este “hilo” es, de hecho, una línea física que conecta cada ranura de expansión así como cada interfaz E/S a la placa madre. Para una ranura ISA de 8 bits, por ejemplo, hay 8 líneas IRQ que unen ranuras ISA de 8 bits a la placa madre (IRQ0 a IRQ7). Estos IRQ están controlados por un “controlador de interrupción” que se encarga de “cederle la palabra” al IRQ que posee la mayor prioridad.
Los métodos interrupt que se manejan en Java. Son 3
1. Interrupt()
2. Interrupted()
3. isInterrupted()
Interrupciones Sintaxis
Public void interrupt () Interrumpe este thread
Primero el método checkAccess de este thread es invocado, lo cual puede causar una Security Exception.
Si este thread es bloqueado al invocar el wait(), wait(long), o wait(long, int) métodos de la clase objeto, o de los métodos join(), join(long), join(long,int), sleep(long), o sleep(long, int) de esta clase entonces los mismos interrupts(de la misma clase) serán despejados y se recibirá un Interrupted Exception.
Si este thread es bloqueado en una operación de E/S ante un canal interrumpidle, entonces el canal se cerrará, el estado de interrupt del thread se fijara, y el thread recibirá un Closed by Interrupt Exception.
Si este thread es bloqueado en un selector, entonces el estado del thread de intrrupt será fijado, y retornara inmediatamente de la operación de selección, posiblemente con un valor diferente a cero, justo como si el método del selector wakeup hubiera sido invocado.
Si ninguna de las condiciones pasadas se cumple, entonces el estado en interrupt del thread será fijado (activado).
Throws: Secutity Exception. Si el thread actual no puede cambiar el thread.
Interrupted (interrumpido)
Sintaxis Public static boolean interrupted ()
Hace una prueba si el thread actual a sido interrumpido. El estado de interrupción del thread es deshecho por este método. En otras palabras, si este método se llamara dos veces, la segunda vez devolvería un valor falso (al menos que el thread actual sea interrumpido de nuevo, después de que la primera llamada haya terminado su interrupción y antes de que la segunda empiece).
Returns: Verdadero si el thread actual a sido interrumpido, falso de lo contrario
IsInterrupted
Sintaxis Public boolean isInterrupted () Hace una prueba para ver si este thread a sido interrumpido. El estado de interrupción del thread no es afectado por este método.
6.2 Generalidades de los puertos.
Canales
Grupos de cables a través de los cuales viaja la información entre los componentes del sistema. Tienen 8, 16 o 32 cables y este número indica la cantidad de bits de información que puede transmitir al mismo tiempo.
Los canales más anchos pueden transmitir información con más rapidez que los canales angostos. Ranuras de expansión: Se conectan al bus eléctrico común. Algunos canales están conectados a ellas en la caja del computador.
Los usuarios pueden personalizar sus máquinas insertando tarjetas de circuitos (o tarjetas) de propósito especial en estas ranuras. Existen tarjetas de expansión de RAM, adaptadores de color y de gráficos, fax módem, puertos, coprocesadores (procesadores adicionales que incrementan la capacidad o velocidad de procesamiento del sistema), etc.
Puertos
Son puntos de conexión en la parte exterior del chasis de la computadora a los que se conectan algunos canales. El puerto permite una conexión directa con el bus eléctrico común de la PC. los puertos pueden ser:
Puertos series
Permiten la transmisión en serie de datos, un bit a la vez. Este tipo de puertos permiten una interfaz con impresoras y módems de baja velocidad.
Puertos paralelos
Permiten la transmisión paralela de datos, es decir que se transmiten varios bits simultáneamente. Permiten la interfaz con dispositivos tales como impresoras de alta velocidad, unidades de cinta magnética de respaldo y otras computadoras. Las ranuras de expansión y los puertos simplifican la adición de dispositivos externos o periféricos.’‘’
6.3 Puerto serial y sus variantes.
Puerto serial:
El puerto serial es aquel que envía y recibe los datos BIT por BIT, entre los puertos seriales se puede mencionar el puerto de teclado, o el puerto del MODEM.
6.3.1 USB.
El Universal Serial Bus (bus universal en serie) o Conductor Universal en Serie (CUS), abreviado comúnmente USB, es un puerto que sirve para conectar periféricos a una computadora.
El diseño del USB tenía en mente eliminar la necesidad de adquirir tarjetas separadas para poner en los puertos bus ISA o PCI, y mejorar las capacidades plug-and-play permitiendo a esos dispositivos ser conectados o desconectados al sistema sin necesidad de reiniciar. Sin embargo, en aplicaciones donde se necesita ancho de banda para grandes transferencias de datos, o si se necesita una latencia baja, los buses PCI o PCIe salen ganando. Igualmente sucede si la aplicación requiere de robustez industrial. A favor del bus USB, cabe decir que cuando se conecta un nuevo dispositivo, el servidor lo enumera y agrega el software necesario para que pueda funcionar.
6.4 Paralelo y sus variantes.
Puerto paralelo:
Este tipo de puerto transmite la información byte por byte, o sea que transmite ocho bits al mismo tiempo, de forma paralela. Un puerto paralelo por excelencia pues es el puerto para impresora
Se puede observar que un puerto de entrada puede ser paralelo o serial, lo mismo que un puerto de entrada o de entrada / salida.
A cada puerto la BIOS le asigna una dirección de memoria para que pueda trabajar, dependiendo de que clase de puerto sea se le asigna un determinado espacio exclusivo para él. Por medio de estas localidades de memoria el sistema puede enviarles o recibir información, es una especie de memoria de intercambio para la transmisión de dados de un lugar a otro. A esto se le llama espacio de localidades de memoria y se realiza dentro del primer kilo bite de la memoria principal. Existen otras asignaciones de memoria en otras capas superiores de memoria pero estas son hechas por el sistema operativo y por los demás programas, pero estas asignaciones son para fines específicos de los demás programas.
Los puertos no solo se limitan a recibir la información, o enviarla, según sea el caso. El puerto provee la corriente eléctrica necesaria para el funcionamiento del dispositivo y revisa el estado de este.
6.5 Interrupciones que intervienen en cada puerto.
Manejo de la interrupción del puerto paralelo.
El bit 4 del puerto de control se denomina IRQEN. Este bit habilita o permite que se produzca la interrupción asociada a la entrada ACK#. Cuando este bit está a 1 y la señal ACK# pasa del nivel lógico 1 al nivel 0 se produce una petición de interrupción, que es la IRQ7.
En el diseño original del PC, IBM reservó 8 interrupciones hardware, comenzando por la interrupción 08h, para expansión de interrupciones, que son comúnmente conocidas como IRQ0 a IRQ7. Así la IRQ0 se corresponde con la interrupción 08h, la IRQ1 con la 09h, etc. La IRQ7 se corresponde pues con la 0Fh, estando sus vectores a partir de la dirección 0000:003Ch.
Para que una petición de una IRQ llegue a la CPU, ésta debe estar permitida, no enmascarada. El puerto 021h está asociado con la máscara de interrupciones de las IRQ.
Para habilitar una determinada interrupción se deberá escribir un cero en la posición correspondiente, sin modificar el resto. Así, si lo que se quiere es permitir la IRQ7 habrá que poner a cero el bit más significativo del puerto 021h, como muestra el código siguiente:
in al,021h ; lee la máscara de las IRQ
and al, 01111111b ; impone un 0 en el bit más significativo, IRQ7. No modifica el resto
out 021h, al ; escribe la máscara
Con estas operaciones quedará habilitada la IRQ7. Una vez atendida de la forma que se haya previsto, el programa debe indicar a la CPU que la interrupción ya ha sido procesada, para ello debe escribir un 1 en el bit 5 del puerto 020h, es decir:
mov al, 020h ; carga en al 0010 0000 b
out 020h, al ; lo escribe en al puerto 020h
Finalmente, tan sólo queda por activar el bit que permite que la señal ACK# genere una petición de IRQ7. Para ello se deberá poner a 1 el bit 4 del puerto de control , sin modificar el resto. Cuando no se quiera que se produzca una IRQ7, basta con poner a cero este bit.
Al finalizar el programa, no sólo se deben restablecer los vectores de interrupción modificados, sino que también se debe inhibir la IRQ7, dejando la máscara del puerto 021h como estaba.
Un programa que utilice la interrupción del puerto paralelo puede tener esta estructura, en lo que se refiere al manejo de dicha interrupción
6.6 Envío y recepción de los datos.
Además de proporcionar un protocolo, el modelo ISO de comunicaciones utilizado por TCP/IP también se aplica en este caso en que hay una capa eléctrica, teniendo por encima una capa muy simple de transporte de bytes. Por ejemplo, la pila PPP puede utilizar el API de Comunicaciones Java para la transferencia de bytes al módem, tanto en un sentido como en otro. El trabajo con la capa de Comunicaciones es realmente poco cuando se usa en este contexto, las tareas a realizar serían:
1. Proporcionar al API de Comunicaciones Java control sobre alguno de los dispositivos. Antes de usar un dispositivo, el API debe conocerlo.
2. Abrir el dispositivo y acondicionar la línea a la velocidad, paridad, etc. que se requiera.
3. Escribir o leer algunos datos siguiendo el protocolo especificado para el dispositivo. Por ejemplo, si hay que comunicarse con una impresora, se pueden enviar los códigos de inicio y fin de trabajo.
4. Cerrar el puerto.
A continuación se verán estos pasos detalladamente, con ejemplos de código de la forma de realizar estas tareas.
Inicialización del API con puertos serie
El API de Comunicaciones Java solamente puede controlar puertos de los cuales tenga conocimiento. En la última versión que JavaSoft ha proporcionado de este API, no es necesario que se inicialicen los puertos, ya que en el arranque, el API realiza una búsqueda de los puertos disponibles en la máquina en que se ejecuta y los va incorporando automáticamente.
Se pueden inicializar los puertos serie que se vayan a utilizar en la aplicación, y en caso de que la nomenclatura de los dispositivos no siga la convención habitual, se pueden añadir explícitamente utilizando código semejante al que se reproduce a continuación.
// Registro del dispositivo
CommPort ttya = new javax.comm.solaris.SolarisSerial( "ttya","/dev/ttya" );
CommPortIdentifier.addPort( ttya,CommPortIdentifier.PORT_SERIAL );
CommPort ttyb = new javax.comm.solaris.SolarisSerial( "ttyb","/dev/ttyb" );
CommPortIdentifier.addPort( ttyb,CommPortIdentifier.PORT_SERIAL );
Apertura y Acondicionamiento de Dispositivos
El código que aparece a continuación muestra como se añade, fijan las características y abre un dispositivo; si el lector necesita detalles específicos sobre los parámetros de las llamadas a los métodos, debe remitirse a la documentación del API. El ejemplo fija un dispositivo serie determinado para que sea accesible con el nombre ControlPuertoSerie. El dispositivo conectado a esta línea tiene una velocidad de 9600 baudios, 1 bit de parada, 8 bits por carácter y no dispone de paridad, y lo que se pretende es proporcionar dos canales, o streams, uno para leer y otro para escribir en el dispositivo conectado a este puerto.
InputStream entrada = null;
OutputStream salida;
SerialPort puertoSerie = null;
public ControlPuertoSerie( String dispositivo,int baudios,int timeout ) throws Exception {
CommPortIdentifier idPuerto =
CommPortIdentifier.getPortIdentifier( dispositivo );
puertoSerie = (SerialPort)idPuerto.openPort( "PuertoSerie",timeout );
puertoSerie.setSerialPortParams( 9600,SerialPort.DATABITS_8,
SerialPort.STOPBITS_1,SerialPort.PARITY_NONE );
puertoSerie.setFlowcontrolMode( SerialPort.FLOWCTRL_NONE );
puertoSerie.enableRcvThreshold( 1 );
puertoSerie.enableRcvTimeout( timeout );
System.out.println( "Dispositivo Serie abierto" );
salida = puertoSerie.getOutputStream();
entrada = puertoSerie.getInputStream();
Escritura y Lectura de datos
En el caso del API de Comunicaciones Java, la lectura y escritura no se diferencia en nada de cualquier llamada a métodos semejantes para realizar estas mismas tareas en objetos derivados del uso de streams.
Para escribir, se puede hacer:
try {
salida.write( arraySalida,0,longitud );
Y para la lectura de datos, es suficiente con hacer:
try {
int b = entrada.read()
6.7 Ejemplos de programación entre puertos y dispositivos.
El ejemplo java1901.java, es un ejemplo muy simple que permite escribir por el primer puerto serie de la máquina en que se esté ejecutando.
import java.io.*;
import java.util.*;
import javax.comm.*;
public class java1901 {
static Enumeration listaPuertos;
static CommPortIdentifier idPuerto;
static String mensaje = "Tutorial de Java, Comunicaciones Serie\n";
static SerialPort puertoSerie;
static OutputStream salida;
public static void main( String[] args ) {
listaPuertos = CommPortIdentifier.getPortIdentifiers();
while( listaPuertos.hasMoreElements() ) {
idPuerto = (CommPortIdentifier)listaPuertos.nextElement();
if( idPuerto.getPortType() == CommPortIdentifier.PORT_SERIAL ) {
// if( idPuerto.getName().equals("/dev/term/a") ) {
if( idPuerto.getName().equals("COM1") ) {
// Si el puerto no está en uso, se intenta abrir
try {
puertoSerie = ( SerialPort )idPuerto.open("AplEscritura",2000);
} catch( PortInUseException e ) {}
// Se obtiene un canal de salida
try {
salida = puertoSerie.getOutputStream();
} catch( IOException e ) {}
// Se fijan los parámetros de comunicación del puerto
try {
puertoSerie.setSerialPortParams( 9600,
SerialPort.DATABITS_8,
SerialPort.STOPBITS_1,
SerialPort.PARITY_NONE );
} catch( UnsupportedCommOperationException e ) {}
// Se envía el mensaje
try {
salida.write( mensaje.getBytes() );
} catch( IOException e ) {}
}
}
}
}
}
Y el ejemplo java1902.java, es la contrapartida, una aplicación también muy simple, que permite leer toda la información que llegue a través del primer puerto serie de la máquina en que se este ejecutando; como lo único que interesa es la lectura de datos, no se tienen en cuenta ninguno de los eventos que generan las demás señales de control del puerto, solamente aquella que indica que hay datos disponibles para leer.
Cierre de Puertos
El cierre de los puertos con este API de Comunicaciones no es distinto a otras peticiones de cierre de dispositivos; aunque en este caso, el cierre es un paso sumamente importante porque el API de Comunicaciones Java siempre intenta proporcionar acceso exclusivo a los dispositivos, y si algún canal no se cierra, no estará disponible para otras aplicaciones. Si se quiere utilizar un dispositivo para múltiples usuarios sobre una misma línea serie, es necesario emplear un protocolo que permita multiplexar la información proveniente de cada uno de ellos.
try {
entrada.close();
salida.close();
} ...
Conclusión
Ahora bien, se puede plantear el problema de que el lector tiene a su disposición un ordenador con puertos serie, y un dispositivo que quiere conectar a través de uno de los puertos, pero no dispone de la implementación del driver correspondiente, y el fabricante todavía no la tiene disponible, solamente proporciona, en el manual del dispositivo, una somera información de cómo se podría acceder al dispositivo a través de llamadas realizadas en C. Y el problema que se plantea es cómo, a través del uso de javax.comm se puede utilizar este dispositivo especial. La respuesta pasa por implementar un interfaz que se comunique con ese dispositivo a través de métodos nativos.
Habría que comprobar el comportamiento del API de Comunicaciones Java ante grandes avalanchas de datos o aplicaciones en tiempo real, en donde sí se puede valorar la bondad de API. No obstante esa duda, la aproximación tan disciplinada que proporciona este API de
Comunicaciones hará mucho más sencilla la integración de cualquier dispositivo serie como lectores de códigos de barras, impresoras, lectores de tarjetas, y cientos de otros dispositivos.
También es verdad que hay otros APIs de Java que se apoyan en este API de Comunicaciones; por ejemplo, si el lector necesita desarrollar una aaplicación que utilice tarjetas inteligentes, puede utilizar un API ya definido como OpenCard Framework, o comunicarse directamente utilizando javax.comm; e incluso, usando javax.smartcard, que hace uso de javax.comm.
Como recomendación final al lector, en caso de que desee utilizar este API en aplicaciones con gran trasiego de datos, o sensiblemente críticas, debe valorar las siguientes cuestiones, para comprobar que el uso de este API satisface los requerimientos que deban tener esas aplicaciones.
• Caracteres perdidos a la entrada
• Caracteres perdidos a la salida
• Frecuencia del flujo de control
• Tiempo que tarda en despachar un evento
• Tiempo de procesado de un carácter
• Tiempo de procesado de un bloque de datos
.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Tópicos selectos de programación Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SCM - 0435 Horas teoría-horas práctica-créditos 3-2-8
2.- HISTORIA DEL PROGRAMA
Lugar y fecha de elaboración o Participantes revisión Instituto Tecnológico Representantes de la de Toluca del academia de sistemas y 18 al 22 agosto 2003. computación de los Institutos Tecnológicos. Instituto Tecnológico de: Cd. Cuauhtémoc, Chihuahua II, Nogales. 23 agosto al 7 de noviembre 2003.
Observaciones (cambios y justificación) Reunión nacional de evaluación curricular de la carrera de Ingeniería en Sistemas Computacionales.
Academia de sistemas y Análisis y enriquecimiento de computación. las propuestas de los programas diseñados en la reunión nacional de evaluación.
Instituto Tecnológico Comité de consolidación de León de la carrera de 1 al 5 de marzo 2004. Ingeniería en Sistemas Computacionales.
Definición de los programas de estudio de la carrera de Ingeniería en Sistemas Computacionales.
3.- UBICACIÓN DE LA ASIGNATURA a). Relación con otras asignaturas del plan de estudio Anteriores Asignaturas Temas Programación Arreglos Orientada a unidimensionales Objetos y multidimensionales Métodos y mensajes Constructor, destructor Sobrecarga Herencia Posteriores Asignaturas Temas Sistemas Administración de operativos. procesos y del procesador. Administración de entrada/salida Administración de memoria
b). Aportación de la asignatura al perfil del egresado • • • Desarrolla sistemas de información, programación de redes de computadora, sistemas distribuidos, de base y aplicación. Desarrolla interfaces de software hombre-máquina, máquina-máquina. Aplica nuevas tecnologías a la solución de problemas de su entorno laboral.
4.- OBJETIVO(S) GENERAL(ES) DEL CURSO El estudiante integrará tópicos avanzados de programación al desarrollo de aplicaciones que requieran multihilo, multimedia, interfaz grafica de usuario y comunicación con puertos.
5.- TEMARIO Unidad Temas 1 Tipos de datos definidos por el usuario. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Subtemas Agregación de datos (struct). Uniones de datos (union). Registros variantes. Tipos de datos enumerados. Manejo de bits. Campos de bits. Operaciones con Bits ( AND, OR, NOT, XOR).
2 3
Creación de componentes y librerías dinámicas Programación concurrente multihilo.
2.1 Creación de componentes. 2.2 Creación de librerías dinámicas. 3.1 Concepto de Hilo. 3.2 Comparación de un programa de flujo único contra uno de flujo múltiple. 3.3 Creación y control de hilos. 3.3.1 Atributos de hilos. 3.3.2 Creación e Inicialización de hilos. 3.3.3 Arranque de hilos. 3.3.4 Manipulación de hilos. 3.3.5 Suspensión de hilos. 3.3.6 Parada de hilos. 3.4 Sincronización de hilos. 3.4.1 Mutex. 3.4.2 Semáforos. 3.4.3 Barreras (Barrier). 4.1 Creación de interfaz gráfica para usuarios. 4.1.1 Librería de interfaz gráfica (API’s). 4.1.2 Aplicaciones GUI. 4.2 Computación gráfica. 4.2.1 Área de dibujo. 4.2.2 Primitivas de dibujo (línea, arco, circulo, colores, rellenos, imágenes).
4
Interfaz Gráfica de Usuario (GUI).
5.- TEMARIO (Continuación) 5 Multimedia. 5.1 Introducción a la multimedia. 5.2 Componentes de un sistema multimedia. 5.3 Formatos de archivo multimedia. 5.4 Creación y manipulación de objetos con formatos de archivo gráfico comunes (GIF, TIFF, JPEG, WMF). 5.5 Creación y manipulación de objetos con formatos de animación y video comunes (AVI, QUICKTIME, MPEG, GIF animado). 5.6 Creación y manipulación de objetos con formatos de audio (compresión de sonido, formato MIDI, MP3). 5.7 Integración de los elementos multimedia. 5.8 Interactividad. 6.1 Interrupciones. 6.2 Generalidades de los puertos. 6.3 Puerto serial y sus variantes. 6.3.1 USB. 6.3.2 Infrarrojo. 6.3.3 Fire wire. 6.4 Paralelo y sus variantes. 6.5 Interrupciones que intervienen en cada puerto. 6.5.1 Direcciones bases. 6.5.2 Registros. 6.6 Envío y recepción de los datos. 6.7 Ejemplos de programación entre puertos y dispositivos.
6
Programación de puertos e interrupciones.
6.- APRENDIZAJES REQUERIDOS • • • • • Comprender la metodología de orientación a objetos. Diseñar soluciones orientadas a objetos. Desarrollar programas orientados a objetos. Comprender los conceptos de la arquitectura de computadoras. Desarrollar aplicaciones en lenguaje ensamblador.
7.- SUGERENCIAS DIDÁCTICAS • • • • • • • • • • Propiciar la búsqueda y selección de información de tecnologías emergentes sobre programación avanzada, mediante equipos analizar y discutir en clase. Realizar las prácticas propuestas para poder alcanzar el objetivo de la materia. Ejercicios extra clase. Analizar prácticas modelo para comprender su funcionamiento. Realizar búsquedas de información sobre temas afines. Elaborar reportes o informes de las prácticas. Realizar practicas de comunicación con dispositivos externos. Propiciar debate en clase sobre la optimización de los algoritmos y códigos de programación. Asignar proyectos finales que integren los temas de este programa de estudio. Exponer los proyectos finales
8.- SUGERENCIAS DE EVALUACIÓN • • • • • • Desempeño, dominio de los conceptos la capacidad de la aplicación de los conocimientos en problemas reales (trasferencia del conocimiento). Cumplimiento de los objetivos de las practicas y del proyecto final. Dar seguimiento al desempeño integral del estudiante en el desarrollo del programa. Exámenes prácticos y teóricos. Realización de programas de aplicación. Desarrollo de un proyecto final que integre todas las unidades de aprendizaje.
9.- UNIDADES DE APRENDIZAJE UNIDAD 1.- Tipos de datos definidos por el usuario. Objetivo Educacional El estudiante creará tipos de datos complejos utilizando estructuras de datos definidas por el usuario Fuentes de Información Buscar y seleccionar información sobre 1, 2, 3, 4, 5, 6, 7 ,8 ,9 las opciones de tipos de datos definidos por el usuario de acuerdo a la sintaxis del lenguaje de programación empleado. Elaborar programas sobre manejo de bits. Actividades de Aprendizaje
•
•
UNIDAD 2.- Creación de componentes y librerías dinámicas. Objetivo Educacional Desarrollará componentes y librerías dinámicas que respondan a las necesidades de desarrollo de aplicaciones Actividades de Aprendizaje • • Buscar y seleccionar información para crear componentes y librerías dinámicas. Elaborar programas simples creando componentes derivados de los ya existentes, introduciendo cada una de las propiedades que definen al componente. Realizar programas para estudiar la metodología de creación de librerías dinámicas. Fuentes de Información 5, 6, 7, 8, 10
•
UNIDAD 3.- Programación concurrente multihilo. Objetivo Educacional Implementara • aplicaciones multihilo compartiendo la • misma arquitectura • • • • Actividades de Aprendizaje Buscar y seleccionar información sobre hilos. Organizar un debate sobre hilos vs. procesos. Analizar uso e impacto de hilos en el desarrollo de aplicaciones. Desarrollar programas para reforzar el uso de hilos con énfasis en los cambios de estado. Desarrollar programas concurrentes que comparten recursos. Debatir problemas de exclusión mutua y formas de resolverla. Fuentes de Información 1, 2, 3, 4, 6, 7, 9
UNIDAD 4.- Interfaz Gráfica de Usuario. Objetivo Educacional Implementará aplicaciones con interfaz gráfica de usuario. Actividades de Aprendizaje • • • • Buscar y seleccionar librerías para creación de interfaz gráfica de usuario. Desarrollar aplicaciones con interfaz gráfica de usuario, que utilice múltiples ventanas. Buscar y seleccionar librerías de computación gráfica. Desarrollar aplicaciones que permitan crear gráficos en tiempo de ejecución. Fuentes de Información 1, 2, 3, 4, 6, 7, 9
UNIDAD 5.- Multimedia. Objetivo Educacional Comprenderá que es • la multimedia, cuales son sus ventajas y • desarrollará una aplicación multimedia interactiva. • Actividades de Aprendizaje Buscar y seleccionar información para discutir sobre la multimedia. Elaborar un mapa conceptual sobre los tipos de formatos gráficos más comunes. Buscar y seleccionar información sobre las herramientas y clases que provee el lenguaje para crear y manipular objetos multimedia. Desarrollar programas para aplicar alguna biblioteca de clases para el manejo de multimedia. Fuentes de Información 1, 6, 8
•
UNIDAD 6.- Programación de puertos e interrupciones. Objetivo Educacional Programará • aplicaciones que requieran los puertos de comunicación. • • Actividades de Aprendizaje Desarrollar programas que incluyan los parámetros programables que intervienen los puertos de comunicación. Buscar y seleccionar información sobre la detección de dispositivos conectados a un puerto. Elaborar aplicaciones para manejo de interrupciones y parámetros utilizados en programas de envío y recepción de datos. Elaborar un mapa conceptual sobre los tipos de formatos gráficos más comunes. Buscar y seleccionar información sobre las herramientas y clases que provee el lenguaje para crear y manipular objetos multimedia. Desarrollar programas para aplicar alguna biblioteca de clases para el manejo de multimedia. Fuentes de Información 10
• •
•
10. FUENTES DE INFORMACIÓN 1. 2. 3. 4. Deitel y Deitel. Como programar en Java.Prentice Hall. 1998. Mitchell will David. Java sin errores. Mc Graw Hill. 2001 Becerril C. Francisco. Java a su alcance. Mc Graw Hill. 1998 Lemay Laura & Perkins Charles L. Aprendiendo Java en 21 días. Prentice Hall. 1996. 5. Smiley John. Learn to program with Java.Mc Graw Hill. 2002. 6. Naughton Patrick . The Java Handbook. Berkeley, CA: OsborneMcGraw Hill. 1996. 7. Schildt Herbert. The Complete Reference Java 2. Fourth Edition. McGraw-Hill. 2001. 8. Case Bradley Julia & Millspaugh Anita C. Mt. San Antonio College. Programming With Java W/CD-ROM. Mc Graw Hill. 2002. 9. Arnow David M. & Weiss Gerald. Introducción a la programación con Java. Un enfoque orientado a objetos. Addison Wesley. 2001. 10. Elliotte Rusty Harold. Java I/O O. O'Reilly & Associates. 1999. 11. Scott Oaks and Henry Wong. Java Threads, second Edition. O'Reilly & Associates. 1999.
Referencias en Internet
[1] [2] [3]
www.bibitec.org.mx www.programacion.com/java/tutorial/java_basico/ www.java.com/
11. PRÁCTICAS Unidad Práctica 1 1 Desarrollar un programa que implemente el uso de tipos definidos por el usuario que respondan a un problema real. 2 1 2 3 1 2 Crear varios componentes y librerías dinámicas que respondan a requerimientos generales. Desarrollar un programa que utilice los componentes y librerías dinámicas creados en la práctica anterior. Desarrollar un programa que permita la creación y control de hilos, incluyendo cambios de estado de cada uno de ellos.. Desarrollar un programa que integre varios hilos que compartan recursos entre ellos e implemente un mecanismo de control de recursos. Desarrollar un programa que incluya la planeación, asignación de prioridades, comunicación con hilos y monitorización. Desarrollar un programa de ordenamiento de cajón (Bucket sort) usando múltiples hilos. Desarrollar un programa que tenga una interfaz grafica de usuario. Desarrollar un programa que permita la creación de gráficos en tiempo de ejecución. Desarrollar un programa que cuente con todos los elementos de multimedia (audio, video, gráficos, texto) y que sea interactivo. Desarrollar un programa que permita leer y escribir en los distintos puertos de la computadora. Desarrollar un programa que permita detectar un dispositivo conectado a uno de los puertos e indique el estado del mismo.. Desarrollar una aplicación para manejo de interrupciones y parámetros utilizados en un programa de envío y recepción de datos.
3
4 4 1 2 5 1
6
1 2
3
INSTITUTO TECNOLOGICO
SUPERIOR DE HUATUSCO
NOMBRE DEL ALUMNO:
MARÍA GUADALUPE NAMORADO MORALES
NOMBRE DE LA MATERIA:
TOPICOS SELECTOS DE PRGRAMACIÓN
NOMBRE DEL DOCENTE:
ING.JUAN MANUEL GONZÁLEZ SOBAL
PROGRAMAS
UNIDAD I
UNIDAD II
Unidad I
Manejadores de Capas
1.- FlowLayout
import javax.swing.*;
import java.awt.*;
public class EjercicioFL extends JFrame {
JButton alumno;
JButton maestro;
JButton escuela;
JButton materia;
public EjercicioFL () {
super.setTitle("FlowLayout");
FlowLayout u= new FlowLayout();
this.setLayout(u);
alumno=new JButton("ALUMNO");
maestro=new JButton("MAESTRO");
escuela=new JButton("ESCUELA");
materia=new JButton("MATERIA");
this.add(alumno);
this.add(maestro);
this.add(escuela);
this.add(materia);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
this.setSize(210, 140);
}
public static void main(String[] args) {
EjercicioFL u=new EjercicioFL();
u.setVisible(true);
}
}// fin de la Capa FlowLayout
2.- BorderLayout
import java.awt.*;
import javax.swing.*;
public class EjercicioBL extends JFrame {
public EjercicioBL() {
super.setTitle("BorderLayout");
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
this.add( new Button( "Sur" ),"South" );
this.add( new Button( "Oeste" ),"West" );
this.add( new Button( "Este" ),"North" );
this.add( new Button( "Boton del Este" ),"East" );
this.add( new Button( "Centro" ),"Center" );
this.setSize( 260,160 );
this.setVisible( true );
}
public static void main( String []args ) {
EjercicioBL x = new EjercicioBL();
x.setVisible(true);
}
}//Fin de BorderLayout
3.- GridLayout
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class EjercicioGL extends JFrame implements ActionListener {
private JButton botones[];
private final String nombres[] =
{ "1", "2", "3", "4", "5", "6" };
private boolean alternar = true;
private Container contenedor;
private GridLayout cuadricula1, cuadricula2;
// configurar GUI
public EjercicioGL()
{
super( "Ejemplo GridLayout" );
cuadricula1 = new GridLayout( 2, 3, 10, 10 );
cuadricula2 = new GridLayout( 3, 2 );
contenedor = getContentPane();
contenedor.setLayout( cuadricula1 );
botones = new JButton[ nombres.length ];
for ( int cuenta = 0; cuenta < nombres.length; cuenta++ ) {
botones[ cuenta ] = new JButton( nombres[ cuenta ] );
botones[ cuenta ].addActionListener( this );
botones[ cuenta ].setToolTipText("Cambia el esquema de GridLayout");
contenedor.add( botones[ cuenta ] );
}
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
setSize( 300, 150 );
}
public void actionPerformed( ActionEvent evento ) {
if ( alternar )
contenedor.setLayout( cuadricula2 );
else
contenedor.setLayout( cuadricula1 );
alternar = !alternar;
contenedor.validate();
}
public static void main( String args[] )
{
EjercicioGL x = new EjercicioGL();
x.setVisible(true);
}
}//Fin de la Capa GridLayout
4.- BoxLayout
import java.awt.*;
import javax.swing.*;
public class EjercicioGBL extends JFrame {
public EjercicioGBL()
{
super( "Demo de BoxLayout" );
// crear contenedores Box con esquema BoxLayout
Box horizontal1 = Box.createHorizontalBox();
Box vertical1 = Box.createVerticalBox();
Box horizontal2 = Box.createHorizontalBox();
Box vertical2 = Box.createVerticalBox();
final int TAMANIO = 3; // número de botones en cada contenedor Box
// agregar botones al objeto Box horizontal1
for ( int cuenta = 0; cuenta < TAMANIO; cuenta++ )
horizontal1.add( new JButton( "Botón " + cuenta ) );
// crear montante y agregar botones al objeto Box vertical1
for ( int cuenta = 0; cuenta < TAMANIO; cuenta++ ) {
vertical1.add( Box.createVerticalStrut( 25 ) );
vertical1.add( new JButton( "Botón " + cuenta ) );
}
// crear pegamento horizontal y agregar botones al objeto Box horizontal2
for ( int cuenta = 0; cuenta < TAMANIO; cuenta++ ) {
horizontal2.add( Box.createHorizontalGlue() );
horizontal2.add( new JButton( "Botón " + cuenta ) );
}
// crear área rígida y agregar botones al objeto Box vertical2
for ( int cuenta = 0; cuenta < TAMANIO; cuenta++ ) {
vertical2.add( Box.createRigidArea( new Dimension( 12, 8 ) ) );
vertical2.add( new JButton( "Botón " + cuenta ) );
}
// crear pegamento vertical y agregar botones al panel
JPanel panel = new JPanel();
panel.setLayout( new BoxLayout( panel, BoxLayout.Y_AXIS ) );
for ( int cuenta = 0; cuenta < TAMANIO; cuenta++ ) {
panel.add( Box.createGlue() );
panel.add( new JButton( "Botón " + cuenta ) );
}
// crear un objeto JTabbedPane
JTabbedPane fichas = new JTabbedPane(
JTabbedPane.TOP, JTabbedPane.SCROLL_TAB_LAYOUT );
// colocar cada contendor en panel con fichas
fichas.addTab( "Cuadro horizontal", horizontal1 );
fichas.addTab( "Cuadro vertical con montantes", vertical1 );
fichas.addTab( "Cuadro horizontal con pegamento", horizontal2 );
fichas.addTab( "Cuadro vertical con áreas rígidas", vertical2 );
fichas.addTab( "Cuadro vertical con pegamento", panel );
getContentPane().add( fichas ); // colocar panel con fichas en el panel de contenido
setSize( 390, 220 );
setVisible( true );
} // fin del constructor
public static void main( String args[] )
{
EjercicioGBL aplicacion = new EjercicioGBL();
aplicacion.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
} }//Fin de BoxLayout
Ejemplos sobre Manejadores de Capas (Clases)
Ejemplo Ventana
import javax.swing.*;
import java.awt.*;
public class Ventana extends JFrame {
JButton b1;
JButton b2;
JButton b3;
JButton b4;
JButton b5;
public Ventana() {
super.setTitle("Ventana");
FlowLayout u= new FlowLayout();
this.setLayout(u);
b1=new JButton("Boton 1");
b2=new JButton("Boton 2");
b3=new JButton("Boton 3");
b4=new JButton("Boton 4");
b5=new JButton("Boton 5");
this.add(b1);
this.add(b2);
this.add(b3);
this.add(b4);
this.add(b5);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
this.setSize(200, 150);
}
public static void main(String[] args) {
Ventana x=new Ventana();
x.setVisible(true);
}
}
Ejemplo Ventana2
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class Ventana2 extends JFrame{
JButton boton;
JLabel Label;
JTextField t1;
public Ventana2() {
super.setTitle("Ventana2");
FlowLayout c=new FlowLayout();
this.setLayout(c);
boton=new JButton("Haga click aqui");
Label=new JLabel("algo");
t1=new JTextField(10);
this.add(boton);
this.add(Label);
this.add(t1);
//-----------------evento----------
boton.addActionListener(new ActionListener() {//Para que haga la accion el boton
public void actionPerformed(ActionEvent e) {//Quien recibe la transformacion
// throw new UnsupportedOperationException("Not supported yet.");
String cadena=t1.getText();
Label.setText(cadena);
}
});
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
this.setSize(200, 150);
}
public static void main(String[] args) {
Ventana2 x=new Ventana2();
x.setVisible(true);
}
}
-----------------------------------------------------------------------------------------
Tarea # 1
Casino Mágico (Juego)
Este Juego genera 3 números aleatorios si los tres son iguales hace una bonificación y también suma los números, verifica y limpia los campos.
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
public class juego extends JFrame{
JLabel l1;
JLabel l2;
JLabel l3;
JTextField n1;
JTextField n2;
JTextField n3;
JLabel suma;
JTextField s;
JTextField r;
JButton generar;
JButton verificar;
JButton limpiar;
JLabel res;
JLabel rl;
public juego() {
super.setTitle("Juego");
FlowLayout capa=new FlowLayout();
// Se crean los componentes
this.setLayout(capa);
l1=new JLabel("Numero 1");
l2=new JLabel("Numero 2");
l3=new JLabel("Numero 3");
n1=new JTextField(10);
n2=new JTextField(10);
n3=new JTextField(10);
suma=new JLabel("Suma");
s=new JTextField(10);
r=new JTextField(10);
generar=new JButton("Generar");
verificar=new JButton("Verificar");
limpiar=new JButton("Limpiar");
res=new JLabel("....El resultado es: ?....");
rl=new JLabel("<<<<Bonificacion>>>>");
// se agregan los componentes
this.add(l1);
this.add(n1);
this.add(l2);
this.add(n2);
this.add(l3);
this.add(n3);
this.add(suma);
this.add(s);
this.add(generar);
this.add(verificar);
this.add(limpiar);
this.add(res);
this.add(rl);
generar.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
//throw new UnsupportedOperationException("Not supported yet.");
try{
int a1,a2,a3;
String cad;
a1=(int)(Math.random()*1000+1);
a2=(int)(Math.random()*1000+1);
a3=(int)(Math.random()*1000+1);
cad=n1.getText();
a1=Integer.parseInt(cad);
cad="";
cad=n2.getText();
a2=Integer.parseInt(cad);
cad="";
cad=n3.getText();
a3=Integer.parseInt(cad);
cad="";
}catch(Exception f){
}
}
});
verificar.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
int r1,r2,r3,r4,s;
String cad;
cad=n1.getText();
r1=Integer.parseInt(cad);
cad="";
cad=n2.getText();
r2=Integer.parseInt(cad);
cad="";
cad=n3.getText();
r3=Integer.parseInt(cad);
cad="";
s=r1+r2+r3;
cad="El resultado es: "+s;
res.setText(cad);
cad=suma.getText();
r4=Integer.parseInt(cad);
cad="";
if(s==r4){
rl.setText("Excelente");
}
else{
rl.setText("Eres un Burroooooo!");
}
}
});
limpiar.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
n1.setText("");
n2.setText("");
n3.setText("");
s.setText("");
}
});
}
public static void main(String[] args) {
juego x=new juego();
x.setVisible(true);
x.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
x.setSize(200,300);
}
}
Promedio
Permite introducir el nombre del alumno y calcula el promedio en número y letra
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
public class Promedio extends JFrame{
JButton lc;
JLabel n;
JLabel e1;
JLabel e2;
JLabel e3;
JLabel e7;
JLabel e5;
JLabel e6;
JLabel e8;
JButton b1;
JLabel e4;
JTextField na;
JTextField t1;
JTextField t2;
JTextField t3;
JTextField t4;
JTextField t5;
JTextField t6;
JTextField t7;
JTextField t8;
JTextField t9;
JLabel l;
public Promedio() {
super.setTitle("Promedio");
FlowLayout capa= new FlowLayout();
this.setLayout(capa);
lc=new JButton("Limpiar Campos");
n=new JLabel("Nombre del alumno");
e1=new JLabel("Topicos Selectos");
e2=new JLabel("Estructura d/datos");
e3=new JLabel("Administracion");
e5= new JLabel("Matematicas 3");
e6= new JLabel("Matematicas 4");
e7= new JLabel("T d/Investigacion");
e8= new JLabel("-----Fisica 2----");
b1= new JButton("Promedio");
e4= new JLabel("Promedio en letra");
na=new JTextField(10);
t1= new JTextField(10);
t2= new JTextField(10);
t3= new JTextField(10);
t4= new JTextField(15);
t5= new JTextField(10);
t6= new JTextField(10);
t7= new JTextField(10);
t8= new JTextField(10);
t9= new JTextField(10);
l=new JLabel("----Promedio en letra----");
this.add(n);
this.add(na);
this.add(e1);
this.add(t1);
this.add(e2);
this.add(t2);
this.add(e3);
this.add(t3);
this.add(e5);
this.add(t5);
this.add(e6);
this.add(t6);
this.add(e7);
this.add(t7);
this.add(e8);
this.add(t8);
this.add(b1);
this.add(t4);
this.add(l);
this.add(lc);
lc.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
na.setText("");
t1.setText("");
t2.setText("");
t3.setText("");
t4.setText("");
t5.setText("");
t6.setText("");
t7.setText("");
t8.setText("");
t9.setText("");
}
}
);
b1.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
try{
int cal1,cal2,cal3,cal5,cal6,cal7,cal8,prom; String cad;
cad=t1.getText();
cal1=Integer.parseInt(cad);
cad="";
cad=t2.getText();
cal2=Integer.parseInt(cad);
cad="";
cad=t3.getText();
cal3=Integer.parseInt(cad);
cad="";
cad=t6.getText();
cal5=Integer.parseInt(cad);
cad="";
cad=t7.getText();
cal6=Integer.parseInt(cad);
cad="";
cad=t8.getText();
cal7=Integer.parseInt(cad);
cad="";
cad=t5.getText();
cal8=Integer.parseInt(cad);
cad="";
prom=(cal1+cal2+cal3+cal5+cal6+cal7+cal8)/7;
cad=""+prom;
t4.setText(cad);
switch(prom){
case 100:
cad="Cien";
l.setText(cad);
break;
case 99:
cad="Noventaynueve";
l.setText(cad);
break;
case 98:
cad="Noventayocho";
l.setText(cad);
break;
case 97:
cad="Noventaysiete";
l.setText(cad);
break;
case 96:
cad="Noventayseis";
l.setText(cad);
break;
case 95:
cad="Noventaycinco";
l.setText(cad);
break;
case 94:
cad="Noventaycuatro";
l.setText(cad);
break;
case 93:
cad="Noventaytres";
l.setText(cad);
break;
case 92:
cad="Noventaydos";
l.setText(cad);
break;
case 91:
cad="Noventayuno";
l.setText(cad);
break;
case 90:
cad="Noventa";
l.setText(cad);
break;
case 89:
cad="Ochentaynueve";
l.setText(cad);
break;
case 88:
cad="Ochentayocho";
l.setText(cad);
break;
case 87:
cad="Ochentaysiete";
l.setText(cad);
break;
case 86:
cad="Ochentayseis";
l.setText(cad);
break;
case 85:
cad="Ochentaycinco";
l.setText(cad);
break;
case 84:
cad="Ochentaycuatro";
l.setText(cad);
break;
case 83:
cad="Ochentaytres";
l.setText(cad);
break;
case 82:
cad="Ochentaydos";
l.setText(cad);
break;
case 81:
cad="Ochentayuno";
l.setText(cad);
break;
case 80:
cad="Ochenta";
l.setText(cad);
break;
case 79:
cad="Setentaynueve";
l.setText(cad);
break;
case 78:
cad="Setentayocho";
l.setText(cad);
break;
case 77:
cad="Setentaysiete";
l.setText(cad);
break;
case 76:
cad="Setentayseis";
l.setText(cad);
break;
case 75:
cad="Setentaycinco";
l.setText(cad);
break;
case 74:
cad="Setentaycuatro";
l.setText(cad);
break;
case 73:
cad="Setentaytres";
l.setText(cad);
break;
case 72:
cad="Setentaydos";
l.setText(cad);
break;
case 71:
cad="Setentayuno";
l.setText(cad);
break;
case 70:
cad="Setenta";
l.setText(cad);
break;
default:
cad="Nos vemos en repite curso";
l.setText(cad);
}
}catch (Exception f){
JOptionPane.showMessageDialog(null,"Error de datos","Error",JOptionPane.ERROR_MESSAGE);
na.setText("");
t1.setText("");
t2.setText("");
t3.setText("");
t6.setText("");
t7.setText("");
t8.setText("");
t5.setText("");
t1.requestFocus();
na.requestFocus();
}
}
});
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
}
public static void main(String[] args) {
Promedio x= new Promedio();
x.setSize(200,530);
x.setVisible(true);
}
}
Equivalencias
El programa realiza una equivalencia de segundos a horas, minutos y segundos
import java.awt.event.ActionEvent;
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionListener;
public class Segundos extends JFrame{
JLabel dn;
JLabel r;
JTextField n;
JButton e;
JButton l;
public Segundos() {
super.setTitle("Segundos");
FlowLayout c=new FlowLayout();
this.setLayout(c);
dn=new JLabel("Dame una cantidad de Segundos");
n=new JTextField(10);
e=new JButton("Equivalencia");
l=new JButton("Nuevo");
r=new JLabel("resultado");
this.add(dn);
this.add(n);
this.add(l);
this.add(e);
this.add(r);
e.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
try{
int numero;
String cad;
cad=n.getText();
numero=Integer.parseInt(cad);
cad="";
int h,m,s,mod;
h=numero/3600;
mod=numero%3600;
m=mod/60;
s=mod%60;
cad="Horas="+h+" Minutos="+m+" Segundos="+s;
r.setText(cad);
}catch(Exception f){
JOptionPane.showMessageDialog(null,"Error de datos", "Error",JOptionPane.ERROR_MESSAGE);
}
}
});
l.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
n.setText("");
}
});
}
public static void main(String[] args) {
Segundos x=new Segundos();
x.setVisible(true);
x.setSize(400, 100);
x.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
}
}
Tabla de Multiplicar
Solo muestra la tabla de multiplicar de cualquier número en orden de menor a mayor.
import java.awt.event.ActionEvent;
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionListener;
public class tabla extends JFrame{
JLabel l1;
JTextField n;
JButton verificar;
JButton limpiar;
JTextArea Textarea;
public tabla() {
super.setTitle("Tabla de Multiplicar");
FlowLayout capa= new FlowLayout();
this.setLayout(capa);
l1=new JLabel("Dame un numero");
n=new JTextField(10);
verificar=new JButton("Verificar");
limpiar=new JButton("Limpiar Campos");
Textarea = new javax.swing.JTextArea();
Textarea.setAutoscrolls(true);
Textarea.setColumns(10);
Textarea.setRows(15);
this.add(l1);
this.add(n);
this.add(verificar);
this.add(Textarea);
this.add(limpiar);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
verificar.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
int nu,res;String cad;
cad=n.getText();
nu=Integer.parseInt(cad);
cad="";
for(int i=1;i<=10;i++){
res=nu*i;
cad=cad+" "+i+"x"+nu+"="+res+" \n ";
Textarea.setText(cad);
}
}
});
limpiar.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
//throw new UnsupportedOperationException("Not supported yet.");
n.setText("");
Textarea.setText("");
}
});
}
public static void main(String[] args) {
tabla x=new tabla();
x.setSize(300,400);
x.setVisible(true);
}
}
Calculadora
Es solo una calculadora Básica
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class Calculadora extends JFrame implements ActionListener {
boolean nuevo = true;
float resultado_total = 0f;
String ultimo = "=";
Label pantalla = null;
Button b;
JPanel panel, panel2;
public Calculadora() {
setTitle("Calculadora");
setSize(200, 200);
Pantalla();
Teclado();
}
private void Pantalla() {
panel = new JPanel();
panel.setLayout(new GridLayout(1, 1));
pantalla = new Label();
pantalla.setText("0");
pantalla.setAlignment(Label.RIGHT);
pantalla.setForeground(Color.black);
pantalla.setBackground(Color.white);
panel.add(pantalla);
add("North", panel);
}
public void Teclado () {
panel2 = new JPanel();
panel2.setLayout(new GridLayout(4, 4));
addBoton("7", Color.black);
addBoton("8", Color.black);
addBoton("9", Color.black);
addBoton("/", Color.black);
addBoton("4", Color.black);
addBoton("5", Color.black);
addBoton("6", Color.black);
addBoton("*", Color.red);
//addBoton("sqrt", Color.red);
addBoton("1", Color.black);
addBoton("2", Color.black);
addBoton("3", Color.black);
addBoton("-", Color.red);
//addBoton("AC", Color.red);
addBoton("0", Color.black);
//addBoton("+/-", Color.red);
//addBoton(".", Color.red);
addBoton("+", Color.red);
addBoton("=", Color.red);
addBoton("C", Color.red);
add("Center", panel2);
}
private void addBoton(String n, Color color) {
b = new Button(n);
b.setForeground(color);
panel2.add(b);
b.addActionListener( this );
}
public void actionPerformed(ActionEvent event) {
String digit = event.getActionCommand();
String s = pantalla.getText();
// Logic based in a source of Santiago Pavón
float valor = 0;
try {
valor = new Float(s).floatValue();
} catch (Exception e) {
if (!digit.equals("C")) return;
}
if ("0123456789".indexOf(digit) != -1) {
if (nuevo) {
nuevo = false;
pantalla.setText(digit);
} else {
pantalla.setText(s + digit);
}
} else if (digit.equals(".")) {
if (nuevo) {
nuevo = false;
pantalla.setText("0.");
} else {
pantalla.setText(s + digit);
}
} else if (digit.equals("sqrt")) {
valor = (float)Math.sqrt(valor);
pantalla.setText(String.valueOf(valor));
nuevo = true;
} else if (digit.equals("+/-")) {
valor = -valor;
pantalla.setText(String.valueOf(valor));
nuevo = true;
} else if (digit.equals("C")) {
resultado_total = 0;
pantalla.setText("0");
ultimo = "=";
nuevo = true;
} else {
char c = ultimo.charAt(0);
switch (c) {
case '=': resultado_total = valor; break;
case '+': resultado_total += valor; break;
case '-': resultado_total -= valor; break;
case '*': resultado_total *= valor; break;
case '/': resultado_total /= valor; break;
}
ultimo = digit;
nuevo = true;
pantalla.setText(String.valueOf(resultado_total));
}
}
public static void main(String[] args) {
Calculadora cal = new Calculadora();
//cal.show();
cal.setVisible(true);
cal.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
}
}
Suma
Calcula la suma de dos números y manda mensajes
import javax.swing.JOptionPane;
public class mensajes {
public static void main(String[] args) {
String n=JOptionPane.showInputDialog("Introduce tu nombre");
String ap=JOptionPane.showInputDialog("Introduce tus apellidos");
JOptionPane.showMessageDialog(null, "La informacion que estas introduciondo se esta mandado a un sitio que no es seguro.","Informacion",JOptionPane.WARNING_MESSAGE);
JOptionPane.showMessageDialog(null,"Desea continuar?","Cuestion",JOptionPane.QUESTION_MESSAGE);
String n1=JOptionPane.showInputDialog("Introdusca el primer numero");
String n2=JOptionPane.showInputDialog("Introdusca el segundo numero");
try{
int a=Integer.parseInt(n1) ;
int b=Integer.parseInt(n2);
int s=a+b;
JOptionPane.showMessageDialog(null, "El resultado de la suma es: "+s,"Mensaje",JOptionPane.INFORMATION_MESSAGE);
}catch(Exception e){
JOptionPane.showMessageDialog(null, "Error de Dato","Burrooooooo!",JOptionPane.ERROR_MESSAGE);
}
JOptionPane.showMessageDialog(null,"La ejecucion a terminado.","Ejecicon Terminada",JOptionPane.PLAIN_MESSAGE);
}
}
Unidad II
Seleccionar un color en un TextArea
import java.awt.*;
import javax.swing.*;
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener;
/**
*Guadalupe Namorado
*/
public class TextArea extends JPanel{
private JComboBox colores;
private String col[]={"Azul","Rojo","Amarillo","Verde","Naranja","Magenta"};
Color color=Color.CYAN;
JTextArea Textarea;
public TextArea() {
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
Textarea = new javax.swing.JTextArea();
Textarea.setAutoscrolls(true);
Textarea.setColumns(10);
Textarea.setRows(15);
colores=new JComboBox(col);
colores.setMaximumRowCount(6);
colores.addItemListener(new ItemListener(){
public void itemStateChanged(ItemEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
//if(e.getStateChange()==ItemEvent.SELECTED){
int c=colores.getSelectedIndex();
if(c==0)
color=color.BLUE;
else
if(c==1)
color=color.RED;
else
if(c==2)
color=color.YELLOW;
else
if(c==3)
color=color.GREEN;
else
if(c==4)
color=color.ORANGE;
else
if(c==5)
color=color.MAGENTA;
Textarea.setBackground(color);
repaint();
}
});
Textarea.setBackground(color);
add(colores);
add(Textarea);
repaint();
}
public static void main(String[] args) {
JFrame caja=new JFrame("TextArea");
caja.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
TextArea x=new TextArea();
caja.add(x);
caja.setBackground(Color.BLACK);
caja.setSize(300, 300);
caja.setVisible(true);
}
}
Ejemplos de RadioButton
Cambiar formato de letra y Tamaños de un botón
package Radio;
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
import java.awt.peer.FontPeer;
import javax.swing.plaf.basic.BasicComboBoxUI.ItemHandler;
public class RadioButtons extends JFrame {
// atributos
JTextField texto;
JRadioButton rtp;
JRadioButton rtn;
JRadioButton rtc;
JRadioButton rtnc;
Font tplano;
Font tnegrita;
Font tcursiva;
Font tnegritacursiva;
ButtonGroup gruporadiobuttons;
public RadioButtons() {
super("Ejemplo de Radio Buttons");
FlowLayout capa = new FlowLayout();
this.setLayout(capa);
this.setSize(365, 150);
texto = new JTextField(29);
this.add(texto);
// se instancian los radio buttons
rtp = new JRadioButton("Texto Plano", true);
rtn = new JRadioButton("Texto Negritas");
rtc = new JRadioButton("Texto Cursivas");
rtnc = new JRadioButton("Texto Negritas & Cursivas");
// se crea el buttongroup
gruporadiobuttons = new ButtonGroup();
gruporadiobuttons.add(rtp);
gruporadiobuttons.add(rtn);
gruporadiobuttons.add(rtc);
gruporadiobuttons.add(rtnc);
// se crean las fuentes
tplano = new Font("Arial", Font.PLAIN, 14);
tnegrita = new Font("Arial", Font.BOLD, 14);
tcursiva = new Font("Arial", Font.ITALIC, 14);
tnegritacursiva = new Font("Arial", Font.ITALIC + Font.BOLD, 14);
//agregando los radiobuttons a la ventana
this.add(rtp);
this.add(rtn);
this.add(rtc);
this.add(rtnc);
// registrando los eventos de los radiobuttons
rtp.addItemListener(new RadioButtonHandler(tplano));
rtn.addItemListener(new RadioButtonHandler(tnegrita));
rtc.addItemListener(new RadioButtonHandler(tcursiva));
rtnc.addItemListener(new RadioButtonHandler(tnegritacursiva));
}
// clase interna
class RadioButtonHandler implements ItemListener {
Font font;
public RadioButtonHandler( Font f) {
font = f;
}
public void itemStateChanged(ItemEvent e) {
//throw new UnsupportedOperationException("Not supported yet.");
texto.setFont(font);
}
}
public static void main(String[] args) {
RadioButtons ventana = new RadioButtons();
ventana.setVisible(true);
ventana.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
}
}//Fin de RadioButton Para Cambiar Formato de Letra
2.- Ejemplo de RadioButton Tamaños
import java.awt.*;
import java.awt.event.ItemEvent;
import javax.swing.*;
import java.awt.Event.*;
import java.awt.event.ItemListener;
/**
*
* @author guadalupe
*/
public class Botton extends JFrame{
JButton boton;
JRadioButton bp;
JRadioButton bm;
JRadioButton bg;
ButtonGroup gruporadio;
public Botton() {
super("Tamaño RadioButton");
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
this.setSize(400, 400);
//*****Instanciar*******
boton=new JButton("Botton");
// ***********Se instancian los radio Buttons************
bp=new JRadioButton("Tamaño Pequeno",true);
bm=new JRadioButton("Tamaño Mediano",false);
bg=new JRadioButton("Tamaño Grande",false);
// ***********Se crea el button group**********
gruporadio=new ButtonGroup();
gruporadio.add(bp);
gruporadio.add(bm);
gruporadio.add(bg);
//************Agregando los radio buttons a la ventana y el Boton*************
this.add(bp);
this.add(bm);
this.add(bg);
this.add(boton);
//*********Registrando los eventos de los radio buttons*********
bp.addItemListener(new RadioButtonHandler(80,150));
bm.addItemListener(new RadioButtonHandler(150,200));
bg.addItemListener(new RadioButtonHandler(220,350));
}
class RadioButtonHandler implements ItemListener{
int x,y;
public RadioButtonHandler(int x, int y) {
this.x = x;
this.y = y;
}
public void itemStateChanged(ItemEvent e) {
boton.setSize(x, x);
}
}
public static void main(String[] args) {
Botton x=new Botton();
x.setVisible(true);
}
}
Usando colorchooser
package Mezclador;
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
public class Colores extends JFrame {
//-- se declaran atributos
private JButton cambio;
private Color color=Color.LIGHT_GRAY;
private JTextField panel;
public Colores() {
super("Usando el mezclador de colores");
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
panel =new JTextField(20);
panel.setBackground(color);
cambio=new JButton("Cambiar color");
cambio.addActionListener( new ActionListener(){
public void actionPerformed(ActionEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
// se manda a llamar a la ventana para elegir colores
color=JColorChooser.showDialog(Colores.this, "Elije un color", color);
// sino se elije color que se le asigne el mismo color que se le habia asignado al principio
if(color==null){
color=Color.LIGHT_GRAY;
}
panel.setBackground(color);
}
});
// se le agregan los atributos a la ventana
this.add(panel);
this.add(cambio);
this.setSize(440, 130);
this.setVisible(true);
}
}
package Mezclador;
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
public class Colores2 {
public static void main(String[] args) {
Colores x=new Colores();
x.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
Triangulo Cambia Color
package Triangulo;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
/**
*
* @author Administrador
*/
public class Equilatero extends JPanel{
JButton cambio;
Color color=Color.CYAN;
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.DARK_GRAY);
g.setColor(color);
Polygon poli=new Polygon();
poli.addPoint(120, 120);
poli.addPoint( 80, 200);
poli.addPoint( 80, 200);
poli.addPoint( 160, 200);
poli.addPoint( 160, 200);
poli.addPoint( 120, 120);
g.fillPolygon(poli);
}
public Equilatero() {
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
cambio=new JButton("Cambiar color");
cambio.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
//throw new UnsupportedOperationException("Not supported yet.");
color=JColorChooser.showDialog(Equilatero.this, "Elije un color", color);
// sino se elije color que se le asigne el mismo color que se le habia asignado al principio
if(color==null){
color=Color.LIGHT_GRAY;
}
// g.setBackground(color);
}
});
this.add(cambio);
}
public static void main(String[] args) {
JFrame equi= new JFrame("Triangulo Equilatero");
equi.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
equi.setBackground(Color.BLACK);
Equilatero e=new Equilatero();
equi.add(e);
equi.setSize(250, 300);
equi.setVisible(true);
}
}
import java.awt.*;
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener;
import javax.swing.*;
/**
*
* @author Usuario
*/
public class Figura extends JPanel{
private JComboBox colores;
private String col[]={"Azul","Rojo","Amarillo","Verde","Naranja","Blanco"};
Color color=Color.DARK_GRAY;
public Figura() {
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
colores=new JComboBox(col);
colores.setMaximumRowCount(6);
colores.addItemListener(new ItemListener(){
public void itemStateChanged(ItemEvent e) {
// throw new UnsupportedOperationException("Not supported yet.");
//if(e.getStateChange()==ItemEvent.SELECTED){
int c=colores.getSelectedIndex();
if(c==0)
color=color.BLUE;
else
if(c==1)
color=color.RED;
else
if(c==2)
color=color.YELLOW;
else
if(c==3)
color=color.GREEN;
else
if(c==4)
color=color.ORANGE;
else
if(c==5)
color=color.WHITE;
repaint();
}
});
add(colores);
repaint();
}
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.gray);
g.setColor(color);
Polygon poli=new Polygon();
poli.addPoint(100, 10);
poli.addPoint( 90, 60);
poli.addPoint( 90, 60);
poli.addPoint( 40, 70);
poli.addPoint( 40, 70);
poli.addPoint( 80, 80);
poli.addPoint( 80, 80);
poli.addPoint( 40, 130);
poli.addPoint( 40, 130);
poli.addPoint( 100, 100);
poli.addPoint( 100, 100);
poli.addPoint( 160, 130);
poli.addPoint( 160, 130);
poli.addPoint( 120, 80);
poli.addPoint( 120, 80);
poli.addPoint( 170, 70);
poli.addPoint( 170, 70);
poli.addPoint( 110, 60);
poli.addPoint( 100, 10);
poli.addPoint( 110, 60);
g.fillPolygon(poli);
}
public static void main(String[] args) {
JFrame equi= new JFrame("Estrella");
equi.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
equi.setBackground(Color.BLACK);
Figura e=new Figura();
equi.add(e);
equi.setSize(250, 300);
equi.setVisible(true);
}
}
Combox de Imágenes
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
/**
*
* @author Usuario
*/
public class Imagenes extends JFrame{
private JComboBox imagenes;
private JLabel etiqueta;
// se crea un arreglo de los nombres de las imagenes
private String nombres[]={"lupita.jpg","gabo.jpg","3646.bmp","ll.jpg","Te amo !!.gif","gracias.jpg"};
// se crea un arreglo de iconos
private Icon iconos[]={
new ImageIcon (getClass().getResource(nombres[0])),
new ImageIcon (getClass().getResource(nombres[1])),
new ImageIcon (getClass().getResource(nombres[2])),
new ImageIcon (getClass().getResource(nombres[3])),
new ImageIcon (getClass().getResource(nombres[4])),
new ImageIcon (getClass().getResource(nombres[5])),
};
public Imagenes() {
super("Probando JComboBox");
FlowLayout capa=new FlowLayout();
this.setLayout(capa);
imagenes=new JComboBox(nombres);
imagenes.setMaximumRowCount( 3 );// desplegara 3 elementos
// este metodo: addItemListener se utiliza para
imagenes.addItemListener(new ItemListener() {
public void itemStateChanged(ItemEvent event) {
// throw new UnsupportedOperationException("Not supported yet.");
if(event.getStateChange()== ItemEvent.SELECTED)
etiqueta.setIcon(iconos[imagenes.getSelectedIndex()]);
}
});
add(imagenes);
etiqueta=new JLabel(iconos[0]);
add(etiqueta);
}
public static void main(String[] args) {
Imagenes x=new Imagenes();
x.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
x.setSize(350,350);
x.setVisible(true);
}
}
Dibujando Lineas
import java.awt.*;
import javax.swing.*;
public class Lineas extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.BLACK);
// Se crea una linea
g.setColor(Color.red);
g.drawLine(5, 30, 300, 30);
// se crea el rectangulo
g.setColor(Color.BLUE);
g.drawRect(5, 40, 90, 55);
// se crea el cuadrado relleno con un color especifico
g.setColor(Color.LIGHT_GRAY);
g.fillRect(100, 40, 90, 55);
// se crea
g.setColor(Color.ORANGE);
g.fillRoundRect(195, 40, 90, 55, 50, 50);
g.setColor(Color.YELLOW);
g.drawRoundRect(290, 40, 90, 55,20, 20);
g.setColor(Color.yellow);
g.draw3DRect(5, 100,90,55, true);
g.fill3DRect(100, 100,90,55, false);
g.setColor(Color.magenta);
g.drawOval(195, 100,90 ,55);
g.fillOval(290, 100,90,55);
}
}
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Ver_lineas {
public static void main(String[] args) {
JFrame ventana=new JFrame("Dibujando lineas");
ventana.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
Lineas x=new Lineas();
x.setBackground(Color.white);
ventana.add(x);
ventana.setSize(400, 210);
ventana.setVisible(true);
}
}
package Barco;
import java.awt.*;
import javax.swing.*;
public class Barco extends JPanel{
public void paintComponent(Graphics b){
super.paintComponent(b);
this.setBackground(Color.LIGHT_GRAY);
b.setColor(Color.RED);
b.drawLine(20, 140, 200, 140);
b.drawLine(50,200, 160, 200);
b.drawLine(20,140, 50, 200);
b.drawLine(200,140, 160, 200);
b.drawLine(120,20, 120, 140);
b.drawLine(120,20, 90, 60);
b.drawLine(90,60, 120, 60);
}
public static void main(String[] args) {
JFrame barco=new JFrame("Barco");
barco.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Barco b=new Barco();
barco.add(b);
b.setBackground(Color.BLUE);
barco.setSize(230, 250);
barco.setVisible(true);
}
}
package Casa;
import java.awt.*;
import javax.swing.*;
public class Casa extends JPanel{
public void paintComponent(Graphics c){
super.paintComponent(c);
this.setBackground(Color.DARK_GRAY);
c.setColor(Color.GREEN);
c.setColor(Color.LIGHT_GRAY);
c.fillRect(100, 150, 200, 200);
c.drawLine(200, 50, 100, 150);
c.drawLine(300,150, 200, 50);
c.setColor(Color.white);
c.fillRect(130, 180, 40, 40);
c.setColor(Color.WHITE);
c.fillRect(230, 180, 40, 40);
c.setColor(Color.white);
c.fillRect(165, 270, 70, 80);
}
public static void main(String[] args) {
JFrame casa=new JFrame("Casa");
casa.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Casa c= new Casa();
casa.add(c);
casa.setBackground(Color.black);
casa.setSize(400,400);
casa.setVisible(true);
}
}
package Estrella;
import java.awt.*;
import javax.swing.*;
public class Estrella extends JPanel {
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.LIGHT_GRAY);
g.setColor(Color.darkGray);
g.drawLine(100, 10, 90, 60);
g.drawLine(90, 60, 40, 70);
g.drawLine(40, 70, 80, 80);
g.drawLine(80, 80, 40, 130);
g.drawLine(40, 130, 100, 100);
g.drawLine(100, 100, 160, 130);
g.drawLine(160, 130, 120, 80);
g.drawLine(120, 80, 170, 70);
g.drawLine(170, 70, 110, 60);
g.drawLine(100, 10, 110, 60);
}
public static void main(String[] args) {
JFrame est=new JFrame("Estrella");
est.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Estrella e=new Estrella();
est.add(e);
est.setSize(300, 300);
est.setVisible(true);
}
}
package Estrellas;
import java.awt.*;
import javax.swing.*;
public class Estrella extends JPanel{
public void paintComponent(Graphics e){
super.paintComponent(e);
this.setBackground(Color.BLACK);
// Primera Estrella: Roja
e.setColor(Color.RED);
// Triangulo 1
e.drawLine(80, 120, 260, 120);
e.drawLine(80, 120, 170, 260);
e.drawLine(260, 120, 170, 260);
// Triangulo 2
e.drawLine(80, 220, 260, 220);
e.drawLine(80, 220, 170, 80);
e.drawLine(260, 220, 170, 80);
// Segunda Estrella: Naranja
e.setColor(Color.ORANGE);
// Triangulo 1
e.drawLine(50, 100, 290, 100);
e.drawLine(50, 100, 170, 290);
e.drawLine(290, 100, 170, 290);
// Triangulo 2
e.drawLine(50, 240, 290, 240);
e.drawLine(50, 240, 170, 50);
e.drawLine(170, 50, 290, 240);
// Tercera Estrella: Azul cielo
e.setColor(Color.CYAN);
// Triangulo 1
e.drawLine(25, 80, 320, 80);
e.drawLine(25, 80, 170, 315);
e.drawLine(320, 80, 170, 315);
// Triangulo 2
e.drawLine(20, 270, 320, 270);
e.drawLine(20, 270, 172, 20);
e.drawLine(173, 20, 320, 270);
}
public static void main(String[] args) {
JFrame est=new JFrame("Estrella");
est.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Estrella e=new Estrella();
est.add(e);
est.setSize(360, 400);
est.setVisible(true);
}
}
package Exagono;
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Exagono extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.black);
g.setColor(Color.RED);
g.drawLine(60, 30, 30, 60);
g.drawLine(30, 60, 60, 90);
g.drawLine(60, 90, 90, 90);
g.drawLine(90, 90, 120, 60);
g.drawLine(120, 60, 90, 30);
g.drawLine(60, 30, 90, 30);
g.drawLine(60, 30, 90, 90);
g.drawLine(90, 30, 60, 90);
g.drawLine(30, 60, 120, 60);
}
public static void main(String[] args) {
JFrame exa=new JFrame("Exagono");
exa.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Exagono e=new Exagono();
exa.add(e);
exa.setSize(200, 150);
exa.setVisible(true);
}
}
package Greca;
import java.awt.*;
import javax.swing.*;
public class Greca extends JPanel{
public void paintComponent(Graphics d){
super.paintComponent(d);
this.setBackground(Color.black);
d.setColor(Color.green);
d.drawLine(20, 30, 200, 30);
d.drawLine(200,30, 200, 140);
d.drawLine(20,140, 200, 140);
d.drawLine(20,45, 180, 45);
d.drawLine(20,45,20, 140);
d.drawLine(180,45, 180, 120);
d.drawLine(40,120, 180, 120);
d.drawLine(40,60, 40, 120);
d.drawLine(40,60, 160, 60);
d.drawLine(160,60, 160, 100);
d.drawLine(60,100, 160, 100);
d.drawLine(60,75, 60, 100);
d.drawLine(60,75, 140, 75);
d.drawLine(140,75, 140, 90);
}
public static void main(String[] args) {
JFrame ventana =new JFrame("Greca");
ventana.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Greca c=new Greca();
c.setBackground(Color.BLACK);
ventana.add(c);
ventana.setSize(230, 200);
ventana.setVisible(true);
}
}
package Octagono;
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Octagono extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.black);
g.setColor(Color.RED);
g.drawLine(50, 90, 30, 110);
g.drawLine(30, 110, 30, 130);
g.drawLine(30, 130, 50, 150);
g.drawLine(50, 150, 70, 150);
g.drawLine(70, 150, 90, 130);
g.drawLine(90, 130, 90, 110);
g.drawLine(90, 110, 70, 90);
g.drawLine(70, 90, 50, 90);
//g.drawLine(110, 140, 80, 155);
//g.drawLine(80, 155, 60, 180);
}
public static void main(String[] args) {
JFrame pen=new JFrame("Octagono");
pen.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Octagono o=new Octagono();
pen.add(o);
pen.setSize(200, 300);
pen.setVisible(true);
}
}
package Pentagono;
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Pentagono extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.black);
g.setColor(Color.RED);
g.drawLine(80, 120, 50, 140);
g.drawLine(50, 140, 60, 180);
g.drawLine(60, 180, 100, 180);
g.drawLine(100, 180, 110, 140);
g.drawLine(110, 140, 80, 120);
g.drawLine(50, 140, 110, 140);
g.drawLine(50, 140, 80, 155);
g.drawLine(80, 155, 100, 180);
g.drawLine(110, 140, 80, 155);
g.drawLine(80, 155, 60, 180);
}
public static void main(String[] args) {
JFrame pen=new JFrame("Pengono");
pen.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Pentagono p=new Pentagono();
pen.add(p);
pen.setSize(200, 300);
pen.setVisible(true);
}
}
package Triangulos;
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Equilatero extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.black);
g.setColor(Color.RED);
g.drawLine(120, 120, 80, 200);
g.drawLine(80, 200, 160, 200);
g.drawLine(160, 200, 120, 120);
}
public static void main(String[] args) {
JFrame equi=new JFrame("Equilatero");
equi.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Equilatero e=new Equilatero();
equi.add(e);
equi.setSize(250, 300);
equi.setVisible(true);
}
}
package Triangulos;
import java.awt.*;
import javax.swing.*;
/**
*
* @author lupis
*/
public class Escaleno extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
this.setBackground(Color.black);
g.setColor(Color.RED);
g.drawLine(30, 20, 30, 70);
g.drawLine(30, 70, 100, 70);
g.drawLine(30, 20, 100, 70);
g.drawLine(200, 20, 130, 70);
g.drawLine(130, 70, 200, 70);
g.drawLine(200, 20, 200, 70);
}
public static void main(String[] args) {
JFrame esc=new JFrame("Escaleno");
esc.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Escaleno e=new Escaleno();
esc.add(e);
esc.setSize(250, 150);
esc.setVisible(true);
}
}
Usando Figuras 2d Graphics
package java2d;
import java.awt.*;
import javax.swing.*;
import java.awt.Graphics2D.*;
import java.awt.geom.GeneralPath;
import java.util.*;
public class Figuras2d extends JPanel{
public void paintComponent(Graphics g){
super.paintComponent(g);
Random random=new Random();
this.setBackground(Color.BLACK);
// arreglo de puntos
int puntosx[]={55,67,109,73,83,55,27,37,1,43};
int puntosy[]={0,36,36,54,96,72,96,54,36,36};
// se hace un casting pasando graphics g a Graphics2d
Graphics2D g2d=(Graphics2D)g;
// se crea un objeto de la clase Graphics 2d
GeneralPath estrella = new GeneralPath();
// para hacer que la estrella se mueva
estrella.moveTo(puntosx[0],puntosy[0]);
// se crea un ciclo para imprimerlos puntos en la posicion
for(int i=1;i<puntosx.length;i++){
estrella.lineTo(puntosx[i],puntosy[i]);
}
// para cerrar el GeneralPath();
estrella.closePath();
g2d.translate(200, 200);
for(int i=1;i<=20;i++){
g2d.rotate(Math.PI/10);
g2d.setColor(new Color(random.nextInt(256),random.nextInt(256),random.nextInt(256)));
g2d.fill(estrella);
}
}
}
package java2d;
import java.awt.*;
import javax.swing.*;
import javax.swing.JFrame;
public class prueba {
public static void main(String[] args) {
JFrame x=new JFrame("Figura 2D");
x.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Figuras2d y=new Figuras2d();
x.add(y);
x.setBackground(Color.white);
x.setSize(400, 400);
x.setVisible(true);
}
}
--------------------
1Introducción
Denominamos sistemas (o aplicaciones) de tiempo real a aquellos sistemas (o aplicaciones)
de cómputo que tienen que satisfacer requerimientos de tiempo de respuesta explícitos.
Supóngase, por ejemplo, el sistema de software encargado de ordenar el inflado de la bolsa
de aire frontal de un automóvil. En este caso el requerimiento de tiempo de respuesta está
dado porque dicha bolsa de aire tiene que estar completamente inflada antes de que
transcurran los 20 milisegundos posteriores a la detección del choque. De incumplirse esto,
se elimina cualquier utilidad de la bolsa (y del software que la controla) dado que el
pasajero ya se habrá impactado contra el tablero.
En la actualidad, los sistemas de tiempo real juegan un papel vital y cada vez más creciente
en nuestra sociedad. Los mismos se pueden encontrar en muchos sistemas desde los muy
simples, hasta los más complejos. Por ejemplo, pueden hallarse con facilidad en el control
de experimentos de laboratorio, control de los motores de autos, sistemas de mando y
control automáticos, plantas nucleares, sistemas de control de vuelos, plataformas de
lanzamiento espacial y en la robótica. Los sistemas de tiempo real más complejos son muy
costosos por lo que en la actualidad los gobiernos e industrias en los países desarrollados
emplean miles de millones de dólares en diseñarlos, construirlos y probarlos.
La necesidad de satisfacer requerimientos de tiempo da como resultado que los sistemas de
tiempo real demanden, de la plataforma de cómputo que los soportan, requerimientos que
difieren radicalmente de aquellos de los sistemas de “propósito general” (estaciones de
trabajo, sistemas de escritorio, servidores de red).
Los sistemas de tiempo real también tienen que operar con un alto grado de confiabilidad.
Dados los requerimientos de respuesta a tiempo de estos sistemas, un aspecto fundamental
de esta confiabilidad es la necesidad de establecer garantías del cumplimiento de sus
restricciones de tiempo (plazos de respuesta). Estas garantías sólo se consiguen mediante la
realización a priori de cálculos de factibilidad (de planificación) que permiten determinar si
se cumplen los plazos de todas las tareas críticas en tiempo. Estos cálculos toman como
base la frecuencia de ocurrencia de todos los eventos en el sistema, los algoritmos de
planificación de la atención a dichos eventos y la cantidad de tiempo que toma el servirlos
(si acaso estos pueden ser servidos). En algunos sistemas, estos cálculos de factibilidad se
hacen fuera de línea; mientras que en otros, destinados a ambiente más dinámicos, se hacen
en línea conforme varía la carga de trabajo del sistema. En este último caso, si los cálculos
arrojan que es imposible dar servicio a tiempo a los sucesos, el sistema debe decidir sobre
un plan de acción que garantice la respuesta de las tareas críticas en detrimento de las
menos críticas.
Todo el esquema anterior se sostiene bajo dos premisas fundamentales: la capacidad de
caracterizar a priori el comportamiento de la carga de trabajo del sistema y la predecibilidad
temporal de la plataforma de cómputo en general y del sistema operativo en particular. En
Luis Eduardo Leyva del Foyo 12
consecuencia, la característica distintiva de un sistema operativo de tiempo real es la
predecibilidad. Para el logro de esta predecibilidad, este tipo de sistemas operativos tienen
que emplear algoritmos y mecanismos cuyas características temporales puedan ser
predicables y verificables (por ejemplo, el conocimiento de los tiempos de ejecución en el
peor caso de todos los servios del sistema, o de la disponibilidad de memoria física).
Un aspecto determinante para el logro del requerimiento de predecibilidad del sistema
operativo, es el mecanismo mediante el cual se administran los eventos externos que se
presentan durante la ejecución de la aplicación. Para el tratamiento de estos eventos
externos, la generalidad de los sistemas operativos de tiempo real actuales emplea
esquemas de administración de interrupciones que fueron diseñados décadas atrás para
sistemas operativos de “propósito general”. Estos esquemas tienen como propósito
fundamental la respuesta rápida a eventos externos (minimizar la latencia de interrupción) o
el caudal de procesamiento1; sin embargo, presentan serios inconvenientes para el caso de
sistemas de tiempo real confiables. Algunos de los inconvenientes más importantes son:
o La generalidad de los desarrollos teóricos para los análisis de factibilidad de
planificación de los sistemas de tiempo real, consideran sólo un único espacio de
prioridades para todas las actividades en el sistema. Esta suposición contrasta con el
modelo real soportado por el sistema operativo, en el cual las Rutinas de Servicio de
Interrupción o ISRs (“Interrupt Service Routine”) y las tareas poseen espacios de
prioridades y algoritmos de planificación independientes. Como consecuencia, el
empleo de dos espacios de prioridades independientes afecta severamente la capacidad
de predecir el comportamiento temporal del sistema. En los casos en que las ecuaciones
de factibilidad incluyen el efecto de estos dos espacios, se deteriora significativamente
la cota de utilización que garantiza la factibilidad de planificación del sistema.
o La sincronización entre ISRs y tareas se lleva a cabo mediante la inhabilitación de
interrupciones. En consecuencia, los sistemas operativos de tiempo real son incapaces
de ofrecer garantías de la latencia de interrupción para el peor caso.
o Existen severas restricciones en cuanto a los servicios del sistema que se pueden
invocar dentro de las ISRs. Esto a su vez, trae como consecuencia un aumento de la
complejidad de diseño e implementación, que afecta negativamente la confiabilidad del
software resultante.
Por lo anterior podemos afirmar que, aunque estos esquemas tradicionales de
administración de interrupciones son adecuados para sistemas que demandan una alta
capacidad (o caudal) de procesamiento, como por ejemplo los sistemas operativos de red y
de bases de datos; así mismo, presentan severas restricciones para el caso de sistemas que
requieren un alto grado de confiabilidad y, peor aún, carecen del determinismo necesario
para establecer las garantías de respuesta temporal que demandan las aplicaciones de
tiempo real. Estas dificultades son de un grado tal, que incluso algunos investigadores han
optado por eliminar completamente el uso de las interrupciones en los sistemas de tiempo
real.
1 Número de trabajos procesados por unidad de tiempo.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 13
El propósito de este trabajo es diseñar nuevos esquemas de tratamiento de
interrupciones que sean más adecuados para los sistemas operativos destinados a
aplicaciones de tiempo real, fundamentalmente en el área del logro del determinismo
temporal y la confiabilidad.
Para la consecución de nuestro objetivo, partimos de la hipótesis de que, a pesar de que los
esquemas y arquitecturas de administración de interrupciones en los sistemas operativos
actuales dan como resultado la existencia de dos tipos de actividades asíncronas ejecutables
denominadas ISRs y tareas (procesos o hilos), cada una de ellas con esquemas propios de
planificación y sincronización, conceptualmente ambas son actividades asíncronas muy
similares que se ejecutan como consecuencia de un evento asíncrono (señal de software,
vencimiento de tiempo, o señal de petición de interrupción). Es por esto que un mecanismo
completamente integrado de administración (sincronización y planificación) de
interrupciones y tareas es más adecuado para el logro de los objetivos de determinismo
temporal y confiabilidad propios de los sistemas de tiempo real. Como consecuencia de
esto, en este trabajo:
o Analizamos las razones por las cuales los esquemas tradicionales de administración de
interrupciones y tareas no son adecuados para el caso de sistemas operativos de tiempo
real.
o Argumentamos las razones por las cuales, una estrategia completamente integrada para
la administración de interrupciones y tareas es más adecuada para el caso de sistemas
operativos de tiempo real.
o Hacemos una evaluación del esquema completamente integrado propuesto por nosotros
desde el punto de vista de la utilización de la CPU y el tiempo de respuesta a los
eventos externos, e cual permite poner de manifiesto bajo que condiciones pudiera
considerarse más adecuado para el caso de las aplicaciones de tiempo real.
o Presentamos el diseño de un subsistema de administración de interrupciones
transportable a diversas arquitecturas y sistemas operativos que utiliza este modelo y
que fue implementado como parte de nuestro micro-núcleo.
o Proponemos estrategias para la implementación de nuestro esquema integrado sobre un
hardware de interrupciones PC convencional y presentamos los algoritmos de
emulación para estas estrategias.
o Presentamos evidencias experimentales que ponen de manifiesto la viabilidad del
esquema integrado y sus ventajas sobre el esquema de administración tradicional.
El resto de este trabajo se organiza como sigue:
En el Capítulo 2 se da una introducción a los sistemas de tiempo real y el análisis de
factibilidad de planificación seguido de una panorámica del esquema tradicional de
Luis Eduardo Leyva del Foyo 14
administración de interrupciones para luego exponer las dificultades que este presenta para
la realización de sistemas de tiempo real confiables.
En el Capítulo 3 hacemos una exposición del trabajo relacionado en el área. Se da una
panorámica de cómo los distintos sistemas operativos y la comunidad de investigación han
estado resolviendo los diferentes inconvenientes que se han presentado en el manejo de
interrupciones. Esta exposición además tiene el propósito de poner de manifiesto la esfera
de aplicación de estas propuestas y como ellas no han estado específicamente orientadas a
lograr el determinismo temporal que demandan las aplicaciones de tiempo real.
En el Capítulo 4 se presenta el mecanismo completamente integrado que se propone en este
trabajo; así como, se fundamentan las ventajas que para el caso de sistemas de tiempo real
presenta el empleo de este nuevo modelo. Se presenta el diseño de un subsistema de
interrupciones de bajo nivel portable que puede ser utilizado como apoyo para la
incorporación de este modelo en el núcleo de un sistema operativo de tiempo real. Por
último, se hace un contraste del modelo integrado propuesto con las alternativas existentes
para el manejo de interrupciones y la evitación de las interrupciones. Este análisis revela
como el modelo integrado combina las ventajas de estas alternativas y evita sus
inconvenientes.
En el Capítulo 5 se presentan diferentes esquemas de emulación que permiten la realización
de nuestro esquema integrado sobre el hardware de interrupciones convencionales de las
PC. Se presenta el análisis desde el punto de vista de la factibilidad de planificación de cada
una de las estrategias de emulación. Este análisis pone de manifiesto los compromiso entre
respuesta temporal en el peor caso y eficiencia de cada una de las variantes de emulación.
Adicionalmente se presentan los algoritmos que permiten implementar el diseño del
subsistema de interrupciones del capítulo anterior utilizando estos esquemas de emulación.
En el Capítulo 6 se presentan los resultados experimentales recogidos a partir de la
implementación del diseño y los algoritmos antes expuestos en un micro-núcleo
experimental para aplicaciones de tiempo real. Estos resultados ponen de manifiesto la
viabilidad de la implementación del esquema integrado incluso sobre un hardware
convencional y su factibilidad desde el punto de vista de la predecibilidad temporal en el
caso de las aplicaciones de tiempo real.
Por último, en el Capítulo 7 se ofrecen nuestras conclusiones.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 15
2Problemática del Manejo
de Interrupciones
En este capítulo damos a conocer las dificultades que presentan los mecanismos actuales de
manejo de interrupciones para el caso de los sistemas operativos de tiempo real. Primero se
da una caracterización del contexto de la investigación en la cual se definen brevemente las
características más importantes de los sistemas de tiempo real, se introduce el análisis de
factibilidad de planificación y se exponen los requerimientos de los sistemas operativos
destinados al soporte de este tipo de aplicaciones. Posteriormente se da una introducción al
mecanismo de interrupciones del hardware (sección 2.4) y al soporte que generalmente
brindan los sistemas operativos (sean o no de tiempo real) para la administración del
mecanismo de interrupciones del hardware (sección 2.5). Todo esto sirve de marco de
referencia para finalmente presentar las dificultades que presenta este esquema para el caso
de las aplicaciones de tiempo real (sección 2.6).
2.1 Contexto de la Investigación (Sistemas Embebidos y de Tiempo Real)
Dos fuerzas significativas provocan que los sistemas de cómputo penetren cada vez más en
la vida cotidiana de las nuevas generaciones de seres humanos: por un lado está la
necesidad cada vez más creciente en la sociedad moderna de equipos con mayores
prestaciones, más sofisticados e “inteligentes” y por el otro, el rápido avance en el
hardware, la miniaturización y la disminución de su costo. Esto trae como consecuencia
que cada día la computadora se utilice en nuevas esferas de aplicación como un
componente destinado a interactuar y controlar los sistemas y equipos en los cuales se
incorpora. Esto ha llevado a la aparición de los denominados sistemas embebidos o
empotrados.
Un sistema embebido es un sistema de cómputo incluido en otro sistema y que forma parte
esencial de él. Dicho en otras palabras, no se percibe como un sistema de cómputo, sinó
como el sistema de aplicación en sí. Por ejemplo, un teléfono celular o el inyector de
gasolina de un automóvil. Los sistemas embebidos incorporan un conjunto de
características significativas que los diferencian de los sistemas de escritorio. Entre ellas,
una de las más importantes y que está presente en muchos de ellos es la necesidad de operar
en tiempo real.
Un sistema de tiempo real es cualquier actividad de procesamiento de información o
sistema de cómputo que tiene que responder con restricciones de tiempo y de manera
predecible a eventos externos. Stankovic lo define como aquel sistema en el cual la
corrección no sólo depende del resultado lógico del cómputo, sino también del tiempo en el
Luis Eduardo Leyva del Foyo 16
cuál este se produce [88]. Es decir, cada resultado debe darse en un plazo de tiempo
específico, no importa si es largo o pequeño, pero de incumplirse con estos plazos el
resultado final se considera erróneo.
De manera general, las restricciones de tiempo en un sistema de tiempo real pueden ser
arbitrariamente complicadas pero la más común es la existencia de plazos de cumplimiento
que pueden clasificarse como duros (“hard”), firmes (“firm”), o suaves (“soft”). Un plazo
se dice que es duro si la consecuencia de su incumplimiento puede ser catastrófica. Se dice
que un plazo es firme si el resultado producido por la tarea correspondiente, deja de ser útil
expirado el plazo, pero su incumplimiento no provoca consecuencias muy severas. Un
plazo que no es ni duro ni firme se dice que es suave, esto es, el resultado tiene mayor
utilidad si se produce a tiempo pero conserva un valor disminuido pasado el plazo de
cumplimiento.
Una concepción errónea muy común y arraigada es la creencia de que un sistema de tiempo
real sólo tiene que ser rápido. Básicamente, ser rápido generalmente es una condición
necesaria, pero no suficiente. Un sistema de tiempo real necesita cumplir plazos explícitos
y ser rápido en el caso promedio no garantiza este cumplimiento. En su lugar, la
característica fundamental de un sistema de tiempo real es que su comportamiento debe ser
predecible. Esto es, debiera ser posible demostrar en la fase de diseño que todas las
restricciones de tiempo de la aplicación se cumplirán siempre que se cumplan ciertas
condiciones (incluyendo suposiciones de fallos). Esto requiere el conocimiento previo de
las cotas en los tiempos de ejecución y los plazos de todas las tareas de manera que puede
ser analizado formalmente. De este modo, el diseñador puede tener una temprana
advertencia de la inhabilidad del sistema de satisfacer sus requerimientos temporales y
tomar así las acciones correctivas apropiadas. En otras palabras, tiempo real no es
sinónimo de rápido sino de predecible.
2.2 Sistema Operativo para Sistemas Embebidos y de Tiempo Real
Los requerimientos antes descritos traen como consecuencia la necesidad de contar con
sistemas operativos de propósito específicos sobre los cuales poder realizar este tipo de
aplicaciones. A este tipo de sistemas operativos se les conoce como sistemas operativos de
tiempo real.
La característica fundamental de un sistema operativo destinado a aplicaciones de tiempo
real es la predecibilidad [90]; es decir que suministre la capacidad de demostrar o probar
que se satisfacen los requerimientos, sujeto a las suposiciones que se hagan. En especial, en
los sistemas de tiempo real la predecibilidad se refiere a la posibilidad de demostrar el
cumplimiento de los requerimientos temporales aún bajo suposiciones del peor caso. Esta
cualidad está ausente en los sistemas operativos de propósito general. Un sistema operativo
para aplicaciones de tiempo real confiables tiene que satisfacer los siguientes
requerimientos:
o Soporta esquemas de planificación y sincronización que limitan el no determinismo
propio de los sistemas concurrentes con el objetivo de garantizar las restricciones de
tiempo (incluyendo plazos de las tareas).
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 17
o Soporta las necesidades de dominios de aplicación altamente confiables (por
ejemplo soporte para detección de errores y condiciones excepcionales; así como la
supervisión de plazos).
o Suministra un alto grado de control a los programas de usuarios. En un sistema
operativo convencional las aplicaciones de usuario tienen un control muy limitado
sobre funciones del sistema operativo tales como planificación, administración de
memoria, control de dispositivos de E/S. En un sistema en tiempo real, sin embargo,
resulta esencial permitir al usuario un control preciso sobre la prioridad y
características temporales de las tareas, sobre el uso de paginación o intercambio de
procesos y sobre qué procesos deben estar siempre residentes en la memoria
principal.
o Suministra al programador un entorno simple y completamente predecible (conjunto
restringido de servicios del OS con tiempos de respuesta deterministas).
Un aspecto importante a destacar es que un sistema operativo de tiempo real no es un
sistema de tiempo real, un sistema operativo de tiempo real sólo permite el desarrollo
de un sistema de tiempo real, tener tal sistema operativo no evita que sobre el se
desarrolle un sistema que no satisfaga sus requerimientos de tiempo. Si por ejemplo se
construye un sistema que necesita satisfacer restricciones de tiempo utilizando un sistema
operativo de tiempo real pero que tiene que responder a comunicaciones a través de una red
Ethernet, nunca será un sistema de tiempo real duro porque Ethernet como tal no es
predecible. Por supuesto si se decide construir una aplicación encima de un sistema
operativo con multitarea cooperativa como Windows 3.11, el sistema tampoco será de
tiempo real ya que el comportamiento del sistema operativo es impredecible.
En otras palabras, un sistema de tiempo real contiene todos los elementos, incluyendo el
hardware, el sistema operativo y el software específico de la aplicación. Un sistema
operativo de tiempo real es solo un elemento del sistema completo de tiempo real. La
característica fundamental de todos los elementos que lo integran es la predecibilidad.
2.3 Planificación y Análisis de Factibilidad
Los sistemas de tiempo real están compuestos por un conjunto de actividades asíncronas o
tareas que se ejecutan de forma concurrente. El planificador de tareas, es la parte del
sistema operativo que se encarga de asignar el tiempo de CPU a las distintas actividades del
sistema según un algoritmo de planificación. Una característica distintiva de los algoritmos
de planificación de tiempo real con respecto a los algoritmos de planificación de los
sistemas convencionales es que en los primeros, además de la heurística para la asignación
del procesador, es necesario ofrecer un conjunto de modelos analíticos o ecuaciones que
permitan determinar de antemano si el conjunto de tareas es capaz de cumplir sus
restricciones de tiempo.
Los estándares de sistemas operativos de tiempo real actuales están basados casi en su
totalidad en algoritmos de planificación con prioridades estáticas (ver por ejemplo: la
Luis Eduardo Leyva del Foyo 18
Especificación de Tiempo Real para Ada 95 [8][9][94]; la Especificación de Tiempo Real
para Java o RTSJ (“Real-Time Specification for Java” [12][28][100], el Estándar POSIX –
“Portable Operating Systems Interface” de Tiempo Real [32], o las especificaciones
ITRON – “Interfaz for The Real-time Operating system Nucleus” y μITRON [78]). Para
estos algoritmos básicamente existen dos enfoques para la determinación de la factibilidad
de planificación:
o Modelos basados en la máxima utilización del procesador que garantiza que el conjunto
de tareas (τ1
,τ2
, …,τn
) satisfaga sus plazos. Se distinguen dos enfoques fundamentales:
Basado en la utilización total del procesador: se apoya en la ecuación básica del
Análisis de Tasa Monótona o RMA (“Rate Monotonic Analysis”), presentada por Liu y
Layland [60]. Esta se aplica a un conjunto de tareas periódicas independientes que se
planifican usando el algoritmo de Tasa Monótona (asigna prioridades proporcionales a
los períodos – a menor período mayor prioridad). Según este modelo, el conjunto de
tareas es factible de planificar si se cumple que:
n
i
n
i
i n U n
T
C
1
21 1 ( )
donde Ci y Ti son el tiempo de ejecución y el período respectivamente de la tarea i y n
es el número de tareas en el sistema.
Basado en los puntos de planificación (utilización parcial): La condición anterior es
suficiente pero no necesaria. Una condición suficiente y necesaria para el Análisis de
Tasa Monótona fue presentada por Lehoczky, Sha y Ding en [52] y está basada en los
puntos de planificación. Esta establece que un conjunto de n tareas periódicas
independientes, es factible de planificar, para todas las fases entre tareas, si y sólo si:
i
j j
k
k
j T
lT
lT
i i n C
(k,l) R 1
1
1
, 1 ,min
i
donde Ri = { (k, l) k = 1,..., i; l = 1,...,Ti/Tk }
o Modelos basados en la obtención del tiempo de respuesta de las tareas. Este método de
análisis de sistemas de tiempo real es aplicable no sólo al caso en que se emplee el
algoritmo de planificación de Tasa Monótona sino a cualquier algoritmo con
prioridades estáticas.
La ecuación básica de esta técnica, a la que se denomina Análisis de Tiempos de
Respuesta [4][42], establece que un conjunto de tareas es factible de planificar para
todos los desfases entre tareas, si y sólo si, el tiempo de respuesta de la tarea i es menor
o igual al plazo de dicha tarea (Ri Di) y el tiempo de respuesta puede calcularse como:
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 19
j
i
j j
i
i i C
T
R
C R
1
1
El soporte de los modelos anteriores por parte del planificador del sistema operativo de
tiempo real es lo que permite que sobre este se puedan construir sistemas de tiempo real
con la certidumbre de que el conjunto de tareas que conforman la aplicación cumpla con las
restricciones temporales
2.4 Introducción al mecanismo de Interrupciones
Las interrupciones son cambios en el flujo de control, no ocasionados por el programa que
se ejecuta, sino por algún otro suceso que necesita el servicio inmediato de la CPU por lo
general relacionado con los dispositivos de E/S. Por ejemplo, un programa puede pedirle al
controlador de disco que empiece a transferir información y que genere una interrupción
cuando acabe la transferencia.
El controlador de
dispositivo emite
una interrupción.
La CPU termina la
ejecución de la
instrucción actual.
La CPU indica el reconocimiento
de la interrupción al dispositivo.
La CPU sitúa en la pila banderas y el
valor de contador de programa ( PC).
La CPU carga el nuevo valor del
PC con dirección de la interrupción.
Guarda el resto de
la información de
estado de la CPU
Da el servicio que
demanda la
interrupción
Restaura información
de estado de la CPU
Restaura valores
originales del PC
y las banderas
Hardware Software
Figura 1 .Procesamiento de una Interrupción
La Figura 1 muestra, en forma muy simplificada, los pasos y los componentes involucrados
en el manejo de una interrupción. La señal de petición de interrupción provoca que la CPU
detenga el programa en curso, salve su estado (es decir, se guardan todos los contenidos de
los registros de la CPU) y transfiera el control a una Rutina de Servicio de Interrupción,
o ISR (del ingles “Interrupt Service Routine”) la cual realiza alguna acción apropiada para
Luis Eduardo Leyva del Foyo 20
darle servicio a la petición. Al terminar el servicio de la interrupción, se debe continuar el
código interrumpido exactamente en él mismo estado en que estaba cuando tuvo lugar la
interrupción, lo cual se logra restaurando los registros internos al estado que tenían antes de
la interrupción previamente salvado permitiendo continuar el flujo normal de
procesamiento.
Como puede observarse, un concepto clave relacionado con las interrupciones es la
transparencia. Cuando se produce una interrupción, tienen efecto algunas acciones y se
ejecutan algunos códigos, pero cuando todo termina, la computadora se debe regresar
exactamente al mismo estado en que se encontraba antes de la interrupción.
2.4.1 Panorámica del Hardware de Interrupciones
El hardware de un sistema de cómputo puede tener muchos controladores de dispositivos
de E/S por tanto, el mecanismo de interrupción tiene que permitir identificar del origen de
la petición de interrupción. Con ese propósito, por lo general se incluye un determinado
número de líneas de petición de interrupción o IRQ (“interrupt request line”), cada una
asociada con un controlador de dispositivo diferente. A su vez, asociado a cada línea de
petición de interrupción existe un conjunto de localizaciones de memoria (vectores de
interrupción) que mantienen la dirección de inicio de la rutina de manipulación de
interrupción para dicha línea de petición. Cuando un dispositivo específico desea
interrumpir, envía una señal por su línea de petición. Con este arreglo, el contador de
programa de la CPU se modifica según el vector de interrupción que corresponda.
El hardware asocia cada línea de petición de interrupción con un nivel de prioridad de
interrupción. La CPU incluye un registro en el que se almacena la prioridad actual (la
prioridad del procesador). Si el nivel de prioridad actual del procesador es mayor o igual
que la prioridad de la línea de petición de interrupción, se ignora la interrupción. Si no, la
prioridad del procesador pasa a ser la de la línea de interrupción y se transfiere el control al
manejador de interrupción correspondiente. Cuando finaliza el manejador de la
interrupción, se disminuye el nivel de prioridad del procesador y se reanuda la ejecución de
la actividad interrumpida. Observe que el proceso de manejo de interrupción puede ser
interrumpido por interrupciones de mayor prioridad. Como las rutinas de atención
interrupción están expuestas a la interferencia de las propias rutinas de interrupción, la
mejor manera de mantener correcta la administración de interrupciones es asegurarse de
que todas las interrupciones sean transparentes.
Para auxiliar al núcleo de la CPU (“CPU core”) a administrar las diferentes fuentes, es
común contar con un hardware de interrupciones auxiliar (el cual pudiera estar externo o
integrado al propio chip) que comúnmente recibe el nombre de Controlador de
Interrupciones Programables o PIC (“programmable interrupt controller”). El PIC
contiene varias líneas de petición de interrupción IRQ por donde llegan las peticiones
provenientes de los distintos dispositivos externos y una salida de interrupción que utiliza
para solicitarle una interrupción al núcleo de la CPU.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 21
2.4.1.1 Ciclo de reconocimiento de interrupción
La CPU responde a una petición de interrupción con un ciclo de reconocimiento de
interrupción. En la mayoría de las CPUs la respuesta a una interrupción consta de los
siguientes pasos:
1. El dispositivo de hardware genera el pulso o señal de petición de interrupción
2. El controlador de Interrupciones Programables prioriza la petición de interrupción
en relación con las demás peticiones que podrían haberse emitido de forma
simultánea (o estar pendientes) y emite la petición de interrupción al procesador.
3. Si las interrupciones están habilitadas, la CPU responde con un ciclo de bus de
reconocimiento de interrupción.
4. En respuesta al reconocimiento de la CPU, el dispositivo externo (o el PIC si
estuviese presente) sitúa un vector de interrupción en el bus de datos.
5. La CPU lee el vector y lo utiliza (posiblemente de forma indirecta) para obtener la
dirección de la ISR.
6. Por último, la CPU sitúa en la pila el contexto actual, inhabilita las interrupciones, y
salta a la ISR.
CPU
Petición de Interrupción
Reconocimiento
de Interrupción
Vector
EOI
Dispositivo de E/S
PIC
Figura 2. Hardware de Interrupciones
2.4.1.2 Niveles de Control de las Interrupciones
El PIC impone y hace cumplir un esquemas de prioridades a cada una de estas líneas de
petición de interrupción (ver Figura 2). Como consecuencia de este arreglo, existen tres
niveles de control de las interrupciones:
Al nivel de CPU puede inhibirse/habilitarse globalmente la capacidad de la CPU de
reconocer las interrupciones.
Al nivel del PIC es posible enmascarar (inhibir) peticiones de interrupciones
individualmente y/o sobre la base de sus prioridades. Típicamente, existen uno o más
Luis Eduardo Leyva del Foyo 22
registros de mascara de interrupción, con bits individuales que permiten o inhiben
fuentes de interrupciones individuales.
Adicionalmente, para implementar el mecanismo de prioridades de las interrupciones (y
abstenerse de solicitarle una interrupción a la CPU mientras se está dando servicio a una
petición de mayor prioridad), el PIC tiene que llevar la pista de que ISR está procesando
la CPU en todo momento. Con este propósito, cada vez que la CPU reconoce una
petición de interrupción proveniente del PIC, además de enviarle a la CPU un vector de
interrupción que identifica cual ISR debe ejecutar, el PIC también registra que dicha
petición de interrupción se encuentra en servicio. A su vez, el PIC tiene que conocer
cuando la CPU ha finalizado de servir una petición. Con este propósito, luego de que la
ISR ejecuta el servicio apropiado (y antes de retornar de la interrupción) tiene que
notificarlo al PIC enviándole un comando de Fin de Interrupción o EOI (“End of
Interrupt”). En algunas arquitecturas (como por ejemplo la x86) este comando se lleva a
cabo escribiendo de forma explícita un código apropiado a un registro del PIC. En otras
arquitecturas (por ejemplo los procesadores Z80 y Z180) este comando lo suministra de
forma implícita la misma ejecución de la instrucción de Retorno de Interrupción.
A nivel de dispositivo, usualmente existe un registro de control de interrupción con bits
para habilitar o inhabilitar las interrupciones que el dispositivo puede generar.
Adicionalmente, muchos dispositivos requieren que la ISR le envíe un acuse de recibo
explícito y lo “configuren” para una nueva petición (generalmente ambas cosas se
consiguen con un solo comando de respuesta al dispositivo). El acuse de recibo que
debe dar el software (la ISR) a la IRQ está dividido en dos partes: la primera parte es la
que se acaba de mencionar y está dirigida al dispositivo que emitió la petición; mientras
que la segunda, mencionada en el punto anterior, comprende el envío del EOI al PIC.
La primera parte es dependiente de la interrupción mientras que la segunda parte es
dependiente del PIC, por lo que es común para todos los dispositivos en un sistema.
2.5 Modelo Tradicional de Administración de Interrupciones por el Sistema
Operativo
El mecanismo de interrupciones suministra un enlace entre los eventos asíncronos externos
y las rutinas de software que le dan servicio. En otras palabras, las interrupciones señalan la
llegada de eventos externos que provocan la ejecución de ISRs. Conceptualmente esto es lo
mismo que el proceso de señalar cierto evento, como por ejemplo la finalización del uso de
recursos o la disponibilidad de un lugar en el buffer que permite la ejecución de
determinada tarea (que estaba esperando por el buffer).
A pesar de estas similitudes, con el afán de lograr una mayor eficiencia y una menor
latencia en la respuesta a las interrupciones, en general los sistemas operativos ofrecen un
conjunto de mecanismos para el tratamiento de interrupciones totalmente independiente de
aquellos utilizados para la administración de las tareas o procesos concurrentes. Esta
decisión proviene de las diferencias de implantación a nivel del sistema.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 23
Las tareas son una abstracción propia del modelo de concurrencia soportado por el núcleo
del sistema y la responsabilidad de su administración recae completamente en el mismo.
Tradicionalmente, el núcleo brinda servicios para la creación, eliminación, comunicación y
sincronización entre tareas [55].
Las interrupciones, por su parte, son una abstracción del hardware de la computadora y la
responsabilidad de su administración recae fundamentalmente en el mecanismo de
interrupciones del hardware. Este suministra un conjunto de funciones entre las que se
encuentran: la asignación de ISRs suministradas por la aplicación a diferentes señales de
petición de interrupción; conmutación de contexto mediante la salva y restaura automática
de un contexto mínimo de la CPU; la habilitación/inhabilitación de peticiones de
interrupción específicas mediante una máscara de interrupción; y la planificación de las
interrupciones según un esquema de prioridad en hardware.
La mayoría de los sistemas operativos se limitan a suministrar un conjunto de servicios que
permiten a las aplicaciones la ejecución de éstas y posiblemente otras operaciones a un
nivel de abstracción ligeramente superior. En conjunto, estos servicios le dan al usuario la
posibilidad de controlar de forma directa esta abstracción, quizás con un mayor nivel de
seguridad. Sin embargo, ninguna de estas operaciones es necesaria para las tareas ordinarias
no relacionadas con interrupciones.
Al estar fuertemente apoyado en el hardware, este enfoque tiene como ventaja un mejor
desempeño del sistema y un menor costo operativo, razón por la cual ha sido el método
utilizado en la mayoría de los sistemas operativos comerciales, estén estos destinados al
mercado de propósito general o incluso al mercado de aplicaciones de tiempo real.
Sin embargo este enfoque da como resultado que estos sistemas operativos suministren en
realidad dos formas de actividades asíncronas: los procesos o tareas y las ISRs. Asociado a
esto, se suministra un conjunto exclusivo y restringido de primitivas con sintaxis y
semántica diferentes que pueden utilizarse sólo para el código perteneciente a una forma
específica; así como, un conjunto de políticas y algoritmos de administración
independientes para cada caso. La Figura 3 muestra algunos ejemplos de esta dicotomía.
Tareas Manejadores de Interrupción
Iniciación Creación de Tareas Instalación de Rutina de Atención a
Interrupción
Terminación Eliminación de Tares Desinstalación de Rutina de Atención a
Interrupción.
Conmutación
de Contexto
Automática y completamente
transparente al usuario
Requiere ayuda del usuario para salvar
y restaurar el contexto.
Sincronización Explícita mediante mecanismos
IPC (semáforos)
Semiautomática mediante Prioridades
de Hardware
Planificación Determinada por la política del
sistema operativo.
Determinada por el Mecanismo de
Interrupciones del Hardware
Figura 3. Diferentes primitivas para la misma función conceptual.
Luis Eduardo Leyva del Foyo 24
2.5.1 Esquema de Prioridades
Las ISRs son actividades iniciadas por una fuente de interrupción que demanda un servicio
y su planificación corre a cargo del mecanismo de control de interrupciones del hardware
de acuerdo a sus prioridades de hardware. Las tareas por su parte, se activan por eventos
generados por software (que incluyen eventos periódicos) y su planificación la lleva a cabo
el planificador del sistema operativo según sus prioridades de software. Este esquema con
niveles de prioridad de hardware situados por encima de los niveles de prioridad de
software, trae como consecuencia que estas últimas se ejecuten sólo cuando no existan
ISRs listas para utilizar la CPU.
Planificador
del Núcleo.
Hardware de
Interrupciones
Prioridades de
Hardware
Prioridades de
Software
( Manejadores de
Interrupción )
( Tareas )
Máxima
Mínima
Figura 4. Prioridades en el esquema tradicional
En sistemas de propósito general, las tareas no tienen requerimientos estrictos de respuesta
a tiempo y las únicas actividades con requerimientos de respuesta en tiempo real, son las
ISRs. En consecuencia, esta disposición tiene sentido, pues logra una baja latencia en las
respuestas a las peticiones de interrupción, permitiendo que no se pierdan los datos sólo por
el hecho de que otra tarea se esté ejecutando.
2.5.2 Sincronización de Exclusión Mutua entre Actividades Asíncronas
Al analizar los mecanismos de sincronización entre las diferentes actividades asíncronas
que existen en el sistema, hay que considerar tanto la sincronización entre actividades del
mismo tipo, como entre actividades diferentes (ISRs y tareas). Según se muestra en la tabla
de la Figura 5 lo cual se discute a continuación.
En el caso de las tareas, la sincronización entre ellas se realiza usando cualquiera de los
mecanismos existentes para la sincronización entre tareas (semáforos, mutexes, mensajes,
buzones, etc.) que brinde el modelo de sincronización del sistema operativo.
Procesos o tareas Interrupciones
Procesos o Tareas Mecanismos de IPC (semáforos) Inhabilitación/habilitación
Interrupciones Nivel de Prioridad Superior. Prioridades de hardware
Figura 5. Mecanismos de sincronización entre diferentes actividades asíncronas
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 25
Para el caso de las ISRs, la sincronización entre ellas se reduce a la sincronización de
exclusión mutua y la consiguen apoyándose exclusivamente en su propio esquema de
prioridades. Sin embargo, aún así existen alternativas:
El caso más simple (por ejemplo en Windows CE versión 2.0 [95]) es que todos los
niveles de interrupción están habilitados de forma tal que expropian a cualquier tarea.
Sin embargo, al ejecutarse cualquier ISRs, el resto de las peticiones de interrupción
están inhabilitadas. En esta configuración todas las ISRs pueden suponer exclusión
mutua. Este arreglo es adecuado en sistemas en que las peticiones de interrupción
requieren poco procesamiento, pero no es adecuado para sistemas de tiempo real.
El diseño más utilizado consiste en asignarle a cada petición de interrupción una
prioridad y permitir las peticiones de mayor prioridad durante la ejecución de una ISR.
En este esquema, conocido como interrupciones anidadas, cada ISR se ejecuta como
una sección crítica con respecto a las ISRs de menor prioridad y las tareas. Además,
debido a que las interrupciones de la misma prioridad están inhabilitadas, una ISR no
tiene que ejecutarse bajo exclusión mutua consigo misma.
Sin embargo, las dificultades cruciales en el aspecto de la sincronización no están en la
sincronización entre entidades del mismo tipo, sino en la sincronización cruzada entre
tareas e ISRs. Las ISR y las tareas se comunican a través de memoria compartida y todas
las operaciones ejecutadas sobre ésta tienen que ser mutuamente exclusivas. Obsérvese que,
aunque las ISRs son secciones críticas automáticas con respecto a las tareas, lo contrario no
es cierto. Los mecanismos para garantizar el acceso exclusivo a las secciones críticas entre
tareas, no garantizan acceso exclusivo contra las ISRs.
De ninguna forma, una ISR puede bloquear a la tarea interrumpida. Por tanto, la exclusión
mutua entre ISRs y tareas se puede conseguir sólo inhabilitando las interrupciones
mientras se accede al dato compartido. Sin embargo, no es conveniente inhabilitar de forma
innecesaria aquellas interrupciones de mayor prioridad que no interfieren con la sección
crítica de la tarea. Ello afectaría innecesariamente la sensibilidad de respuesta
(“responsiveness”) del sistema a las interrupciones urgentes. Por tanto, los segmentos de
código que usan el nivel de interrupción de la CPU para sincronización deben situarlo sólo
hasta el nivel de prioridad de la ISR con la que pudieran interferir.
En sistemas operativos tradicionales de tipo UNIX, este esquema de sincronización es
adecuado. Ello se debe a que no es posible la ejecución de manejadores de interrupción en
modo usuario, y a que las aplicaciones no pueden modificar el nivel de prioridad de la CPU
(se ejecutan con todas las interrupciones habilitadas). En estos sistemas, sólo es posible
actuar sobre el nivel de interrupción de la CPU cuando las tareas ejecutan el código del
sistema operativo en modo núcleo. Debido a que el núcleo no es expropiable, no existe
ningún peligro de que ocurra una conmutación de contexto mientras ha sido alterado el
nivel de interrupción actual de la CPU. Cualquier elevación del nivel de interrupción de la
CPU, será restaurada antes de que sea posible una conmutación de contexto restringiendo
esta modificación al contexto de la tarea actual.
Luis Eduardo Leyva del Foyo 26
2.6 Dificultades al Usar el Modelo Tradicional en Núcleos para Sistemas Embebidos
y de Tiempo Real.
Aunque muchos sistemas operativos destinados a aplicaciones embebidas y de tiempo real
han optado por utilizar el modelo de administración de interrupciones antes descrito
(sección 2.5), su empleo presenta serias dificultades en este entorno. En esta sección damos
una panorámica de las dificultades que este esquema presenta en cuatro esferas
fundamentales: la sincronización entre los diferentes tipos de actividades asíncronas, su
integración con un mecanismo estructurado de tratamiento de situaciones excepcionales, las
prioridades de planificación y el establecimiento de cotas en la latencia de interrupción.
2.6.1 Dificultades asociadas con el mecanismo de sincronización
En los sistemas embebidos, la diversidad de dispositivos periféricos para la interacción con
el entorno hace inadecuado el modelo de manejadores de dispositivos al nivel del núcleo.
Además, en el caso de los sistemas de tiempo real, un núcleo no expropiable puede
posponer arbitrariamente la conmutación de contexto, dificultando seriamente la capacidad
de predecir el comportamiento temporal. Si el núcleo se hace expropiable, o si se le permite
a las tareas de usuarios actuar directamente sobre el nivel de interrupción de la CPU, es
necesario suministrar protección contra dos errores comunes: el error del cierre de
interrupción roto y el error de las interrupciones dobles/retardadas [97].
2.6.1.1 Errores Debido al Mecanismo de Sincronización de Exclusión Mutua
El problema del cierre de interrupción roto está asociado a la necesidad de rastrear los
niveles de interrupción a través de escenarios con expropiación de tareas. Esta situación se
ilustra en la Figura 6.
En la figura una tarea de alta prioridad TH se bloquea esperando un evento externo que será
señalado por la interrupción IH (instante t1). Ello provoca que comience a ejecutarse una
tarea TL de baja prioridad la cual elevará el nivel de interrupción de la CPU hasta el nivel
correspondiente a IL con el propósito de acceder a una sección crítica que comparte con
dicha ISR (instante t2). Si embargo, mientras se ejecuta en la sección crítica se produce una
interrupción de mayor prioridad que provoca la ejecución de la ISR IH. Esta ISR señala el
evento que desbloquea a la tarea TH (instante t4) provocando que esta expropie a la tarea de
baja prioridad TL dentro de su sección crítica. Como parte de la conmutación de contexto
hacia la tarea TH, el núcleo establece el nivel de interrupción de la CPU asociado a la
misma que pudiera ser inferior al nivel de interrupción de la tarea interrumpida (en este
caso se habilitan todas las interrupciones). Mientras se ejecuta esta nueva tarea TH, puede
ocurrir una interrupción del nivel de prioridad que se quería evitar (IL en el ejemplo). Para
el ejemplo de la figura, de hecho en el instante t4 se produce la interrupción IL provocando
que se ejecute su ISR asociada y violando el requerimiento de exclusión mutua establecido
por la tarea TL. En efecto, la conmutación de contexto ha eliminado el cierre sobre la
sección crítica (entre los instantes t4 y t7 de la figura).
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 27
TL
TH
IL
IH
L(L) U()
Menor Prioridad
Mayor Prioridad
t1 t2 t3 t4 t5 t6 t7 t8 tiempo
ISR de alta prioridad IH activa a la tarea TH que
expropia a TL rompiendo el cierre de interrupción.
Cierre de Interrupción Roto
ISRs
Tareas
Figura 6. Cierre de Interrupción Roto
Una alternativa que se ha empleado, es mantener el estado de las interrupciones sin
cambios al hacer una conmutación de contexto. Aunque esto resuelve los problemas de
seguridad, se hace menos predecible el comportamiento global del sistema porque las tareas
se ejecutarán con varios estados de interrupción, dependiendo de la tarea a la que
expropiaron.
Para evitar este problema, muchos núcleos obligan a que las tareas siempre eleven el nivel
de prioridad de la CPU al más alto posible. Esto inhabilita todas las interrupciones evitando
que una conmutación de tareas destruya el cierre de interrupción.
2.6.1.2 Errores Debido al Mecanismo de Sincronización de Condición
Comúnmente una ISR hará al menos una llamada al núcleo para indicar la ocurrencia de
algún evento. Las operaciones de este tipo (por ejemplo un signal sobre un semáforo) no
pueden bloquear a la tarea interrumpida. Sin embargo, pueden provocar que se ponga lista
una tarea de mayor prioridad. Si se ejecuta la conmutación de contexto, antes de que
finalice la ISR, el resto de la misma no se ejecutará hasta que la tarea interrumpida (en el
contexto de la cual se está ejecutando la ISR) sea ejecutada nuevamente en la CPU. Esto
postergará la actualización de variables importantes del sistema, dejándolo en un estado
inestable. En consecuencia, si estos servicios se invocan dentro de una ISR, el núcleo tiene
que posponer cualquier conmutación de contexto hasta que la ISR haya finalizado, instante
en que tiene que ejecutar cualquier conmutación de tarea pendiente. Por tanto estos
Luis Eduardo Leyva del Foyo 28
servicios se tienen que comportar de forma distinta si son invocados desde una ISR o desde
una tarea. Existen dos alternativas para detectar esta diferencia:
1) Protocolo EnterISR-LeaveISR: requiere que la ISR de la aplicación salve los registros
de la CPU y le notifique al núcleo (mediante un servicio como enterISR()) que se ha
iniciado una ISR. El núcleo incrementará un contador que utiliza para determinar el
nivel de anidamiento de ISRs. Justo antes de finalizar, el código de la ISR invoca a otro
servicio para notificar su salida (por ejemplo leaveISR()). Este disminuye el contador
de anidamiento y al llegar a cero, si hay alguna tarea de mayor prioridad lista, ejecuta la
conmutación de contexto, de lo contrario reanuda la tarea interrumpida. La dificultad
de este esquema es que pudiera ocurrir una interrupción de mayor prioridad antes de
que se atienda la llamada enterISR(). Si esto sucede y se ha solicitado una conmutación
de tarea, la primera ISR no se completará. Las consecuencias de esta implementación
dependen del hardware del sistema:
o Error de doble interrupción: se producirá en sistemas con interrupciones activadas
por nivel y en los cuales el dispositivo que levantó la interrupción original la seguirá
sosteniendo, por lo que se volverá a activar cuando la nueva tarea se comience a
ejecutar (suponiendo que se ejecuta con interrupciones habilitadas).
o Error de demora excesiva: se producirá en sistemas con interrupciones activadas
por flanco. Ésta no se vuelve a activar, pero su servicio se reanudará sólo cuando la
tarea que se estaba ejecutando al inicio de todo el proceso pase nuevamente a ser la
tarea de mayor prioridad.
Este esquema (protocolo EnterISR-LeaveISR) es utilizado en muchos sistemas
operativos de tiempo real como por ejemplo OSEX [70] y C/OS [48].
2) Invocación indirecta de la ISR del usuario: la interrupción transfiere el control
directamente al núcleo del sistema. Esto permite que éste determine si está dentro de
una ISR inspeccionando el indicador de estado de interrupciones de la CPU salvado
automáticamente en la pila al ocurrir la interrupción. Hecho esto, el núcleo invoca a una
rutina de manejo de interrupción suministrada por la aplicación para dar servicio a la
interrupción la cual le devuelve el control (al núcleo) al finalizar. Al regreso, si hay
tareas de mayor prioridad activas, se ejecutará la conmutación de contexto sólo si no
quedan ISRs pendientes de terminar.
La dificultad de este esquema está dada porque una tarea regular pudiera haber elevado
el nivel de prioridad de interrupción para proteger una sección crítica. Si en el
transcurso de ésta se produce una interrupción de mayor prioridad, que activa a una
tarea de mayor prioridad, el código de salida de la ISR supondrá (erróneamente) que se
estaba ejecutando una ISR (ya que se guía por el nivel de interrupción) y pospondrá
cualquier conmutación de tarea. Obsérvese que, aunque este comportamiento resuelve
también el error del cierre de interrupción roto (ver Figura 6) y por tanto es correcto
desde el punto de vista lógico introduce el problema de la conmutación pendiente y por
tanto si constituye un problema para el comportamiento (corrección) temporal del
sistema.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 29
Si la tarea restaurase directamente el nivel de interrupción de la CPU, no existiría forma
de verificar si hay alguna conmutación pendiente y la tarea de alta prioridad se
demoraría indefinidamente. El resultado es una forma extrema de inversión de prioridad
que hace al sistema completamente impredecible temporalmente. Nuevamente, se han
usado dos alternativas para evitar este error de “conmutación muy tarde”:
o Protocolo de habilitación/inhabilitación de interrupciones: las tareas sólo sitúan
el nivel de interrupción de la CPU al nivel más alto. Al no haber ISRs tampoco
podrán ponerse listas tareas de mayor prioridad, por tanto no habrán conmutaciones
pendientes.
o Suministro de primitivas del núcleo: las tareas no modifican directamente el nivel
de interrupción de la CPU, sino que invocan un servicio del núcleo para restaurarlo.
El núcleo puede entonces verificar si, al restituirse al nivel más bajo de prioridad,
hay conmutación de tareas pendiente, y si es el caso ejecutarlas. Esta solución
introduce una menor latencia en la conmutación de contexto y es la utilizada en
SSX5 [97].
Sin embargo, independientemente de la magnitud de la latencia de conmutación de
contexto que introduzcan cualquiera de las alternativas anteriores, el comportamiento
temporal de las mismas es muy difícil de modelar y por tanto de predecir.
2.6.1.3 Dificultades asociadas a la diversidad de mecanismos de sincronización
Las diferencias existentes entre los mecanismos de sincronización utilizados según el tipo
de actividad asíncrona, trae como consecuencia una gran diversidad de situaciones
particulares para la cooperación entre éstas, en donde sólo debiera existir un número
limitado. Como ejemplo, supóngase la sincronización de condición entre las ISRs y las
tareas que se apoya en un esquema productor-consumidor pero sin posibilidad de bloqueo
para el caso de las ISRs. Esta particularidad introduce todo un conjunto de variantes para
manejar los casos que normalmente se tratan suspendiendo al productor o al consumidor y
que ahora se tienen que tratar ya sea desechando el dato o situando datos más frescos o
volviendo a obtener los datos anteriores (entre otras posibilidades). Esto, en dependencia de
la aplicación. Como consecuencia el programador tiene que manejar una cantidad
innecesariamente grande de patrones comunes de diseño [55]. Esta amplia diversidad, en
última instancia hace más probable la ocurrencia de errores de diseño, afectando
adversamente la confiabilidad del software.
2.6.2 Dificultades Asociadas con la Utilización de un Mecanismo Estructurado de
Manejo de Excepciones
Otra dificultad asociada al modelo de dos tipos de actividades asíncronas, aparece al
integrarlo con un mecanismo estructurado de manejo de excepciones [54], en donde las
excepciones se propagan a través de la cadena de llamadas a subprogramas. Si ocurre una
excepción dentro de una ISR, se propagaría al manejador de excepciones actual de la tarea
Luis Eduardo Leyva del Foyo 30
interrumpida, el cual no está preparado para tratar excepciones ocurridas en actividades que
no tienen relación con éste.
La solución consiste en hacer que el mecanismo de propagación de excepciones verifique si
la propagación va a salir de una ISR y si es el caso, detenerla y sólo abortar la ISR. Esto
provoca la necesidad de situar y eliminar un marco de excepción como parte del protocolo
de entrada y salida de la ISR, además de que dichas excepciones pasarían inadvertidas, lo
que constituye una dificultad para la tolerancia a fallos.
2.6.3 Dificultades asociadas a la existencia de dos espacios de prioridades
independientes.
La dificultad asociada al esquema de dos espacios de prioridades independientes en el caso
de aplicaciones de tiempo real, radica en la suposición de que en ningún momento, los
requerimientos de ejecución a tiempo de una tarea, tendrán mayor importancia que los de
una ISR. Esta suposición, válida en sistemas de propósito general, no se sostiene en
sistemas de tiempo real, en donde además, los requerimientos de respuesta a tiempo para
algunas interrupciones pueden estar incluso en el mismo rango que los de las tareas con
altas frecuencias de activación (por ejemplo en una medición periódica).
Ambos espacios de prioridades pueden interactuar de forma que interfieran el uno con el
otro. En específico, las tareas de mayor prioridad del sistema quedan constantemente bajo
la interferencia de los eventos de hardware necesarios sólo para tareas de baja prioridad. Es
posible que las tareas de baja prioridad o incluso tareas con requerimientos de tiempo real
suave que estén asociadas a interrupciones de E/S (por ejemplo la atención al operador) no
puedan ejecutarse debido a sobrecargas temporales y; sin embargo, sus respectivas
interrupciones se siguen produciendo. Esta situación afecta significativamente la capacidad
de cumplir con los plazos de las tareas y se manifiesta como una disminución en la cota
máxima permisible de utilización de la CPU para que el conjunto de tareas sea factible de
planificar.
2.6.4 Dificultad asociada con el logro de latencias de interrupciones acotadas
Aunque los argumentos antes expuestos en contra del modelo tradicional de manejo de
interrupciones son ya de por sí muy importantes, no son los únicos. Quizás el argumento
más significativo contra de este modelo se puede encontrar en su misma razón de ser:
disminuir al mínimo la latencia de las interrupciones. El único parámetro determinante en la
latencia de interrupción sobre el cuál puede actuar el núcleo del sistema operativo es el
tiempo en que se inhabilitan las interrupciones. Con el propósito de minimizar la latencia
de interrupción estos sistemas hacen todo su esfuerzo por inhabilitar las interrupciones sólo
por períodos de tiempo muy breves. Sin embargo, simultáneamente, este diseño no puede
impedir que las aplicaciones inhabiliten las interrupciones ya que es la única forma posible
de sincronización entre tareas e ISRs.
En realidad, la respuesta del sistema como un todo a las interrupciones no puede ser mejor
que el tiempo máximo por el cual se inhiben las interrupciones en cualquier parte del
sistema. Como la aplicación puede inhabilitar las interrupciones por más tiempo que el
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 31
núcleo, si ello ocurre, la latencia de interrupción en el peor caso será la suma de la latencia
introducida por la CPU y el peor caso del tiempo con interrupciones inhabilitadas de la
aplicación. En conclusión, lo más que puede hacer el núcleo es establecer una cota mínima
en la latencia de interrupción, pero nunca garantizar la latencia de interrupción en el peor
caso. Esta última, queda siempre en manos de aplicación.
2.7 Resumen
El modelo de administración de interrupciones actualmente en uso en los sistemas de
tiempo real arroja una rápida respuesta a los eventos externos y un menor costo operativo.
Sin embargo, presenta serias dificultades, las cuales exponemos a continuación.
Problemática asociada a los dos espacios de prioridades. En el modelo tradicional, las
(peticiones de) interrupciones siempre tienen mayor prioridad que cualquier tarea o proceso
de cómputo. Por el contrario, en los sistemas de tiempo real, los requerimientos de tiempo
de respuesta de algunas ISRs pueden estar incluso por debajo que cualquier tarea del
sistema. En este caso, ambos espacios de prioridades pueden interactuar de forma que
interfieran el uno con el otro. Específicamente, bajo el modelo tradicional, las tareas de
mayor prioridad podrían quedar bajo la interferencia de eventos de hardware necesarios
sólo para tareas de baja prioridad. Por otro lado, tareas de baja prioridad asociadas a
interrupciones (ejemplo, la atención al operador) podrían no ejecutarse debido a
sobrecargas temporales y sin embargo, sus respectivas ISRs si se ejecutan. Este
comportamiento afecta la capacidad de cumplir los requerimientos de tiempo real del
sistema y se manifiesta como una disminución en la máxima utilización permisible de la
CPU para que el sistema sea factible de planificar.
Problemática asociada a la latencia de interrupciones. Quizás el argumento más
significativo en contra del modelo tradicional se puede encontrar en su propósito
fundamental: disminuir al mínimo la latencia de las interrupciones. Con el propósito de
minimizar esta latencia, el núcleo inhabilita las interrupciones sólo por períodos de tiempo
muy breves. Sin embargo, este diseño no puede impedir que las aplicaciones inhabiliten las
interrupciones, ya que es la única forma posible de sincronización entre tareas e ISRs. En
realidad, el tiempo de respuesta del sistema a las interrupciones no puede ser menor que el
tiempo máximo por el cual se inhiben las interrupciones en cualquier parte del sistema.
Dado que la aplicación puede inhabilitar las interrupciones más tiempo que el núcleo, la
latencia de interrupción en el peor caso será la suma de la latencia introducida por la CPU y
el tiempo de inhabilitación de interrupciones en el peor caso de la aplicación. En
conclusión, en el modelo tradicional lo más que puede hacer el núcleo es establecer una
cota mínima en la latencia de interrupción, pero nunca garantizar su peor caso.
Problemática asociadas al mecanismo de exclusión mutua. Cuando una tarea de baja
prioridad, para acceder a una sección critica que comparte con una ISR de nivel medio,
eleva el nivel de interrupción hasta ese nivel, puede ocurrir una interrupción de nivel alto
que active a una tarea de alta prioridad y expropie a la tarea de baja prioridad. Esto
disminuirá el nivel de interrupción de la CPU, destruyendo el cierre de interrupción de la
tarea de baja prioridad. Para evitar esta situación el núcleo podría mantener el estado de las
interrupciones sin cambios al hacer una conmutación de contexto. Esto afecta la
Luis Eduardo Leyva del Foyo 32
predecibilidad del sistema porque las tareas se ejecutarán con varios estados de
interrupción, dependiendo de cual haya sido la tarea que hubieran expropiado. La
alternativa es obligar a que las tareas siempre sitúen el nivel de interrupción más alto
posible, evitando así cualquier conmutación de contexto. Sin embargo, esta solución
incrementa la latencia en la conmutación de contexto.
Problemática asociada a la sincronización de condición. Comúnmente una ISR hará al
menos una llamada al núcleo para indicar la ocurrencia de algún evento. Esta llamada
puede poner en listo a una tarea de mayor prioridad. Si se ejecuta la conmutación de
contexto, antes de que finalice la ISR, el resto de la misma no se ejecutará hasta que la tarea
interrumpida sea ejecutada, dejando al sistema en estado inestable. En consecuencia, si
estos servicios se invocan dentro de una ISR, el núcleo tendrá que posponer cualquier
conmutación de contexto hasta que la ISR finalice. Todas las soluciones existentes
provistas para el modelo tradicional para resolver este problema y que garantizan la
corrección lógica introducen una excesiva inversión de prioridad por demoras en la
conmutación de contexto o exhiben un comportamiento temporal muy difícil de modelar y
por tanto de predecir.
Problemática asociada a la diversidad de mecanismos de sincronización. Las
diferencias existentes entre los mecanismos de sincronización utilizados según el tipo de
actividad asíncrona, trae como resultado una gran diversidad de situaciones para la
cooperación entre estas, donde solo debería existir un número limitado. Esta situación,
produce un aumento en la complejidad de la solución de las interacciones entre estas. Esta
situación hace más probable la ocurrencia de errores de diseño afectando adversamente la
confiabilidad del software.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 33
3Antecedentes y Trabajos
Relacionados
En este capítulo presentamos el modelo de manejo de interrupciones utilizado por varios
sistemas operativos. Se comienza por un análisis del modelo clásico de manejo de
interrupciones de Unix seguido por el esquema utilizado por los sistemas operativos más
modernos destinados a entornos de red y aplicaciones multimedia. Durante la exposición se
ponen de manifiesto las dificultades fundamentales que cada uno de esos modelos
presentaron y cómo estas se han ido resolviendo en los sistemas más recientes y por la
comunidad de investigación. Posteriormente se analizan los esquemas utilizados en la
actualidad por los sistemas embebidos y de tiempo real. A lo largo de esta exposición se
pone de manifiesto como los sistemas operativos de tiempo real actuales han adoptado
modelos de manejo de interrupciones diseñados décadas atrás para los sistemas de
propósito general. Por último, concluimos destacando que ninguna de estas soluciones
resuelve todos los problemas planteados en el capítulo anterior (sección 2.6).
3.1 Tratamiento de las Interrupciones en los sistemas Unix Clásicos
La mayoría de los sistemas de tiempo compartido se basan en el concepto de
interrupciones. Los mejores exponentes de este tipo de sistemas operativos son los sistemas
Unix clásicos (Unix Sexta Edición AT&T [59] y versiones de Berkeley previas al BSD 4.2
[72]).
3.1.1 Núcleo dividido en dos mitades
En los sistemas Unix clásicos el software del sistema operativo (y de manejo de los
dispositivos) estaba dividido en una mitad superior (“top half”) y una mitad inferior
(“bottom half”)2. La mitad superior suministra servicios a los procesos y se ejecuta de
forma procedural en el contexto del proceso actual en respuesta a llamadas al sistema. Por
su parte, la mitad inferior incluye todo el código que se ejecuta como parte de las ISRs.
Estas se ejecutan de forma asíncrona (“asynchronous”) con respecto a la mitad superior y
en el contexto de cualquier proceso que se encuentre activo en el sistema cuando se recibe
la petición de interrupción. Las mitades superior e inferior del núcleo se comunican a través
de estructuras de datos, generalmente organizadas alrededor de colas de trabajo. Esta
arquitectura ha sido ampliamente utilizada por muchos otros sistemas operativos, al punto
2 No confundir esto con los manejadores de interrupción “top half” y “bottom half” de Linux. La terminología
“top halt” y “bottom half” fue acuñada por el Unix BSD [64] para referirse al código de la mitad superior e
inferior del núcleo respectivamente y es en este sentido (completamente diferente al significado Linux) que se
usa aquí.
Luis Eduardo Leyva del Foyo 34
que Schmidth y Cranor acuñaron el término Half-Sync/Half-Async para referirse a este
patrón arquitectónico [84].
3.1.2 Núcleo no expropiable
Para evitar el acceso concurrente a las estructuras de datos internas del núcleo por
diferentes procesos (y los problemas de corrupción de datos derivados de ello), el núcleo de
los sistemas Unix tradicionales es no expropiable (“non-preemptible”). Esto significa que
nunca se le quita la CPU a un proceso mientras se ejecuta en la mitad superior del núcleo
(dentro de una llamada al sistema) para darle el control a otro proceso. Esto no sucede ni
siquiera cuando la interrupción del reloj detecta que ha vencido el cuanto de tiempo del
proceso actual mientras está dentro del núcleo. Si esto sucede, la replanificación (o
invocación del planificador para llevar a cabo la conmutación de contexto) no tiene lugar
inmediatamente; en su lugar, la ISR del reloj simplemente activa una bandera interna del
núcleo3 para indicarle a éste que ejecute el planificador después de que se haya finalizado la
llamada al sistema y se esté por devolver el control al modo usuario4. El resto de las
interrupciones se comportan de igual modo y nunca provocan de forma directa una
replanificación; en su lugar, sólo solicitan que esta se produzca (cuando sea posible) y
siempre devuelven el control al mismo código del núcleo que se estaba ejecutando previo a
la interrupción.
Dentro (de la mitad superior) del núcleo de Unix los procesos deben renunciar
voluntariamente a la CPU. Típicamente esto sucede en dos situaciones: (1) Cuando un
proceso ha finalizado sus actividades en modo núcleo y está en camino de retornar al modo
usuario (si verifica que la bandera interna solicita una replanificación – según se dijo antes);
y (2) cuando requiere esperar por algún recurso o evento externo.
3.1.3 Sincronización de condición dentro del núcleo (y entre mitad superior e inferior)
Es común que un proceso ejecutando el código (de la mitad superior) del núcleo necesite
esperar a que finalice algún evento. El ejemplo más obvio es una E/S: cuando un proceso
emite una petición de E/S, el manejador de dispositivo correspondiente inicia la operación
de transferencia de E/S; sin embargo, puede pasar un largo tiempo antes de que ésta
finalice. Cuando se completa la transferencia, el dispositivo emite una interrupción, de
modo que es la ISR (dentro del manejador de dispositivo) se entere que la transferencia
finalizó y le notifica al proceso. En Unix esta sincronización se lleva a cabo mediante un
protocolo de dormirse/despertar mediante las funciones sleep y wakeup. La mitad
superior del manejador invoca a sleep cuando quiere esperar por un evento, y la mitad
inferior invoca a wakeup cuando ocurre el evento según se muestra en la Figura 7. En más
detalle:
3 El nombre original de esta bandera en la edición 6 de At&T en SVR3 y BSD 4.3 era runrun y en Linux,
esta bandera tiene el nombre de need_resched.
4 Mientras el proceso se ejecuta en modo usuario (corriendo el programa de la aplicación) es completamente
expropiable. Usualmente, cuando se recibe una interrupción del reloj y el proceso se encuentra en modo
usuario (ejecutando el programa de aplicación), la ISR del reloj dentro del núcleo invoca al planificador de
forma que potencialmente puede suspender la ejecución el proceso actualmente en ejecución y reanudar la
ejecución de otro – el tiempo compartido natural de cualquier sistema Unix.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 35
¿Evento? sleep()
No
sleepqueue wakeup()
Si
¿Evento?
Si
System Call ISR
Maneja Evento
Top half
Bottom half
Figura 7 . Sincronización de condición sleep()/wakeUp() dentro del núcleo
o El proceso emite una llamada al sistema (por ejemplo read()), la cual lo lleva a
modo núcleo.
o El servicio read() localiza el manejador de dispositivo asociado el dispositivo de E/S
y lo invoca para iniciar la transferencia.
o A continuación read() invoca a sleep; pasándole la dirección de algún objeto único
relacionado con la petición. sleep almacena la dirección en una estructura asociada al
proceso, marca al proceso como durmiendo y libera al procesador. En este punto el
proceso está durmiendo.
o En algún instante posterior, cuando la petición se completa, la ISR dentro del
manejador de dispositivo invoca a wakeup() con la dirección que le fue pasada a
sleep(). Wakeup() barre la lista de procesos durmiendo y despierta a todos los
procesos esperando en esta dirección específica.
3.1.4 Sincronización de exclusión mutua entre la mitad superior y la inferior
El carácter no expropiable del núcleo garantiza que ninguna interrupción pueda afectar el
orden de ejecución del código de la mitad superior del núcleo. Sin embargo, la ejecución de
un proceso dentro del núcleo puede ser interrumpida temporalmente por (una ISR de) la
mitad inferior del núcleo en dependencia del nivel de prioridad de interrupción IPL
(“interrupt priority level”) actual. Cada interrupción de dispositivo tiene asociado un IPL y
sólo puede interrumpir al procesador si su IPL es mayor que el IPL actual. Mientras se
ejecuta una ISR (código del la mitad inferior), el IPL actual se hace corresponder con el
IPL de la interrupción correspondiente.
Para evitar situaciones de carrera durante el acceso a las estructuras de datos compartidas
entre los códigos de la mitad superior e inferior; el código de la mitad superior eleva
temporalmente el IPL (bloqueando las interrupciones correspondientes) mientras accede a
dichas estructuras de datos compartidas. El valor al cual situar el IPL se elige sobre la base
del nivel de prioridad del dispositivo que comparte las estructuras de datos que la mitad
superior va a modificar. Este mecanismo asegura la consistencia de las colas de trabajos y
otras estructuras de datos compartidas entre las mitades superior e inferior.
Luis Eduardo Leyva del Foyo 36
3.1.5 Inconvenientes de esta arquitectura
Este modelo de sincronización mediante la inhabilitación temporal de las interrupciones
posee muchos inconvenientes que afectan el desempeño del sistema:
o Las interrupciones son eventos urgentes e importantes. Mientras estas permanecen
inhabilitadas, quedan suspendidas todas las operaciones de E/S (por interrupción) y
cualquier dispositivo que esté solicitando servicio tendrá que esperar hasta que las
interrupciones se habiliten de nuevo (que puede ser un tiempo potencialmente
largo). Esto puede traer consigo pérdida de datos por desbordamiento (“overrum”)
si se pierden interrupciones5.
o En la mayoría de las arquitecturas de hardware, la habilitación e inhabilitación de
las interrupciones o la elevación o disminución del IPL es una operación costosa
que requiere varias instrucciones de máquina. Como consecuencia, existe una
penalización por la inhabilitación de las interrupciones.
o En sistemas multiprocesadores, estos problemas se magnifican. El núcleo tiene que
proteger mucho más objetos y generalmente tiene que bloquear las interrupciones
en todos los procesadores.
3.2 Tratamiento de las Interrupciones en los Sistemas Operativos de Red
La solución adoptada por los Sistemas Operativos de Red (VMS 1.0+[43], BSD 4.2+[64],
NT [85] y Linux [11]) consiste en dividir la atención a las interrupciones en dos niveles que
puedan operar a diferentes IPLs:
El primer nivel consiste en el manejo convencional de la interrupción (ISR) que se
ejecuta al nivel IPL (alto) de la interrupción correspondiente. Este manejador es
responsable de interactuar directamente con el dispositivo de hardware y de la
administración de buffers; o sea, las funciones que tienen que llevarse a cabo antes de
que sea posible volver a habilitar las interrupciones provenientes del dispositivo
(disminuir el nivel IPL).
El segundo nivel utiliza algún mecanismo de interrupción de software solicitada
desde el manejador de primer nivel (que sitúa en cola la petición) y que permite
postergar el procesamiento de más baja prioridad para que sea ejecutado por un
pequeño planificador que se invoca de forma automática cuando terminan de ejecutarse
las ISRs del primer nivel y baja el IPL. Estos manejadores se ejecutan entonces con
todas las interrupciones de hardware habilitadas. Si se produce alguna otra interrupción
de hardware mientras se está ejecutando el código de esta interrupción de software, esta
última será interrumpida igual que ocurre con las demás tareas de baja prioridad.
Entonces la ISR de primer nivel puede solicitar que se ejecute otra (o incluso la misma)
5 La práctica común para “solucionar” este problema es a través de múltiples iteraciones de pruebas y errores.
En sistemas comerciales es común que se emitan múltiples versiones con errores antes de atinar con la versión
“correcta”.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 37
interrupción de software, pero su ejecución se diferirá hasta tanto la que se está
ejecutando actualmente finalice. Cada ejecución de una interrupción de software de
segundo nivel puede ser interrumpida por una ISR de primer nivel, pero nunca puede
ser interrumpida por otra interrupción de software de segundo nivel similar. En otras
palabras, los manejadores de este segundo nivel nunca pueden ser interrumpidos a si
mismos (se ejecutan hasta terminar).
Esta estructura de dos niveles tiene como propósito reducir significativamente la cantidad
de tiempo durante el cual están inhabilitadas las interrupciones de hardware (nivel IPL alto)
y ello se logra por varios factores:
El código de la parte del núcleo no dirigido por interrupción (mitad superior) sólo
necesita inhabilitar las interrupciones en los casos en que tenga que acceder a
estructuras de datos compartidas con las ISRs. Si se restringen los servicios que pueden
ser invocados desde las ISRs de primer nivel a unos pocos que no acceden a datos
compartidos con la parte del núcleo no dirigida por interrupción (por ejemplo, sólo a la
petición de la interrupción de software de segundo nivel), entonces la parte del núcleo
no dirigida por interrupción no necesitará inhabilitar las interrupciones de hardware.
Aun en los casos en que el núcleo nunca inhabilitara las interrupciones para acceder a
las secciones críticas, ello no significa que estas estén siempre habilitadas. Cada vez
que se recibe una interrupción, el procesador hace una inhabilitación automática de las
interrupciones al elevar el IPL hasta el nivel de la interrupción correspondiente para
transferir el control a la ISR. Al permitir posponer el grueso del procesamiento de la
interrupción a un manejador de segundo nivel con IPL bajo (interrupciones de hardware
habilitadas) se logra mantener en un mínimo el tiempo de inhabilitación automática de
las interrupciones.
Esta arquitectura de dos niveles de procesamiento de interrupción se completa con un
mecanismo que permite inhabilitar (selectivamente) las interrupciones de software de
segundo nivel mientras se ejecuta el código normal de la parte no dirigida por interrupción
del núcleo. El núcleo puede proteger fácilmente sus secciones críticas con los manejadores
de segundo nivel utilizando el siguiente sistema: los manejadores de interrupción siempre
posponen la ejecución de cualquier código que pudiera implicar el acceso a datos
compartidos con la parte no dirigida por interrupción del núcleo para que sea ejecutado en
los manejadores de segundo nivel. Cuando la parte del código del núcleo no dirigida por
interrupción desea entrar en una sección crítica compartida con (los manejadores de
segundo nivel de) la parte dirigida por interrupción, puede inhabilitar a las interrupciones
de software relevantes para evitar que estas los interrumpan. Al final de la sección crítica,
el núcleo puede rehabilitar nuevamente las interrupciones de software y ejecutar cualquier
manejador pendiente que haya sido situada en cola durante la sección crítica por las ISRs
de primer nivel.
La Figura 8 resume los diferentes niveles de protección de interrupciones en el sistema.
Cada nivel puede ser interrumpido por el código ejecutándose a un nivel superior, pero
nunca será interrumpido por código ejecutándose al mismo nivel o a un nivel inferior
Luis Eduardo Leyva del Foyo 38
(excepto para el código de modo usuario que siempre será expropiado por otros procesos
cuando ocurra una interrupción de planificación de tiempo compartido).
Niveles de
Prioridad (IPL) Funcionalidad del código
Alta Manejadores de Interrupción de 1er Nivel (ISRs)
Manejadores de Interrupción de 2do Nivel. Se ejecutan hasta terminar
con todas las interrupciones habilitadas.
Parte del núcleo no dirigido por interrupción (mitad superior).
Comprende el planificador y las rutinas de servicio del núcleo. Este
código es no expropiable.
Baja Programas en modo usuarios. Siempre son expropiables
Figura 8. Niveles de protección de Interrupción
Aunque el propósito y el principio general de esta arquitectura de interrupciones de dos
niveles es el mismo en todos los sistemas, los detalles de implementación y la
denominación del manejador difieren en los distintos sistemas. En algunas arquitecturas
(tales como la VAX [43]), estas interrupciones de software se implementan utilizando
verdaderas trampas de hardware provocadas por instrucciones de máquina de la CPU. En
otras arquitecturas, la misma funcionalidad se implementa completamente en software,
supervisando banderas establecidas por el manejador de interrupción en los instantes de
tiempo adecuados e invocando directamente a las funciones de procesamiento solicitadas
(Llamadas a Procedimientos Diferidos o DPC – “Deferred Procedure Call” – en NT [85],
Mitad inferior – “bottom half” – en Linux[11], Procedimiento de Bifurcación – “Fork
Procedure” en VMS [43]). A continuación se da una panorámica de su implementación en
NT y en Linux.
3.2.1 Manejo de Interrupciones en Windows NT
NT define un conjunto priorizado de Niveles de Petición de Interrupción IRQL (“Interrupt
Request level”) independiente de la arquitectura. Según se muestra en la Figura 9, estos
niveles se hacen corresponder con los niveles de petición de interrupción de hardware; así
como, con niveles de interrupciones de software predefinidos.
Windows NT posee una arquitectura interna muy diferente de la arquitectura monolítica6 de
los núcleos de Unix tradicionales. NT posee una arquitectura alternativa que combina la
arquitectura clásica de micro-núcleo (“micro-kernel”) (introducida por sistemas tales como
Mach [3] y Chorus [5]) con la arquitectura estratificada (introducida por el sistema THE
[30]). El equivalente al núcleo de Unix es lo que en NT recibe el nombre de Ejecutivo. Lo
que se denomina núcleo en NT es sólo una parte muy pequeña del ejecutivo que sólo
implementa un conjunto de mecanismos básicos.
Hasta la versión NT 4.0 la documentación oficial de Intel menciona que el núcleo de NT es
no expropiable [85]; ello quiere decir que, aunque el código del núcleo puede ser
6 La arquitectura monolítica se refiere a grandes rasgos a que todo el sistema operativo está contenido dentro
de un gran núcleo que incluye todas las funciones del sistema operativo.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 39
suspendido temporalmente por una interrupción para la ejecución de una ISR esta siempre
devolverá el control al núcleo sin expropiar al hilo actualmente en ejecución (los hilos
dentro del núcleo no son expropiados ni siquiera cuando se le vence su cuanto de tiempo).
Cuando un hilo que se ejecuta dentro del núcleo (con un nivel IPL 0) necesita esperar por
algún evento, este cede voluntariamente la CPU invocando directamente al planificador
para realizar un cambio de contexto de forma inmediata.
Nombre simbólico Propósito Nivel
Intel
Nivel
Alpha
Nivel Alto Mayor Nivel de Interrupción 31 7
Nivel de Energía Falla de Suministro Eléctrico 30 7
Nivel IPI Señal Inter-Procesador 29 6
Nivel del Reloj Pulso de Reloj 28 5
Nivel de Perfil Monitoreo de Desempeño (historial) 27 3
hardware
Nivel de Dispositivo Interrupciones generales de los Dispositivos 3-26 3-4
Nivel de Despacho Operaciones del Planificador y Llamadas a
Procedimientos Diferidos (DPCs)
2 2
Nivel APC Llamadas a Procedimientos Asícronos 1 1
Software
Nivel Pasivo Todos los niveles de interrupción habilitados 0 0
Figura 9. Niveles de Interrupción independientes de la arquitectura de Windows NT
Si el núcleo detecta la necesidad de realizar una replanificación mientras se encuentra a un
nivel de interrupción elevando (por ejemplo como parte de la ejecución de una Llamada a
Procedimiento Diferida – ver Figura 9) entonces no invoca directamente al planificador
sino que solicita una interrupción de nivel despacho/DPC para activar el planificador.
Como el IRQL está en ese nivel, o en uno superior, el procesador pone la interrupción en
espera. Cuando el núcleo termina su actividad actual, reduce el IRQL por debajo del nivel
despacho/DPC y se activa la interrupción DPC que causa la replanificación.
Aunque los servicios de bajo nivel del núcleo no son expropiables estos son simples y se
ejecutan muy rápidamente de manera que, el hecho de que el núcleo sea no expropiable
ejerce un mínimo impacto en la latencia de expropiación. Adicionalmente, al no ser el
núcleo expropiable se evita el problema de la inversión de prioridad no acotada (situación
en la cual una tarea de alta prioridad ve impedida su ejecución debido a la ejecución de una
tarea de menor prioridad y esto se mantiene por un tiempo no predecible). En NT, el grueso
del código del sistema reside en el ejecutivo, quien implementa las políticas y los servicios
más sofisticados en función de los servicios del núcleo. El ejecutivo se implementa
mediante múltiples hilos y es completamente expropiable. Este diseño minimiza la latencia
de replanificación a la vez que evita el problema de la inversión de prioridades no acotada.
Cuando el núcleo necesita sincronizar el acceso a estructuras internas compartidas que no
son accedidas por las ISRs, no necesita inhabilitar las interrupciones de hardware; sino que,
simplemente eleva el IRQL del procesador al nivel de despacho/DPC. Esto inhabilita todas
las demás interrupciones de software incluyendo la replanificación de hilos. Sólo en el caso
de que se necesite proteger el acceso a datos compartidos entre el núcleo y las ISRs, es que
Luis Eduardo Leyva del Foyo 40
el núcleo de NT eleva el IRQL del procesador hasta un nivel más alto inhabilitando
cualquier fuente de interrupción cuya ISR pudiera acceder a los datos.
Esta estrategia de sincronización funciona en sistemas con un sólo procesador, pero resulta
inadecuada para una configuración multiprocesador. Elevar el IRQL en un procesador no
evita que ocurra una interrupción en otro procesador. El núcleo necesita garantizar también
acceso mutuamente exclusivo a través de los diversos procesadores7.
Para lograr exclusión mutua en un sistema multiprocesador, NT utiliza el mecanismo de
cierre de giro (“spin lock”) asociado a las estructuras de datos globales (compartidas entre
varias CPUs). Mientras el cierre no está disponible la CPU se mantiene en un ciclo
intentando continuamente (en espera ocupada) hasta tanto esté disponible.
Mientras un hilo retiene un cierre de giro, existe el peligro de que algún otro código
activado por una interrupción en la misma CPU intente obtener el mismo cierre de giro. En
esta situación el código activado por la interrupción permanecería girando indefinidamente
debido a que precisamente él está impidiendo el progreso del código que pudiera liberar el
cierre. Para impedir una posibilidad de bloqueo mutuo como esta, los cierres de giros tienen
que primero elevar el nivel de prioridad de interrupción hasta un nivel lo suficientemente
alto y mantenerlo en ese nivel mientras se retiene el cierre (se ejecuta la sección crítica).
Una vez que se libere el cierre, el nivel de interrupción debe disminuirse a su valor previo.
En NT, todos los cierres de giro de modo núcleo poseen un IRQL asociado que siempre se
sitúa a nivel de Despacho o superior. Por lo cual, cuando un hilo está intentando adquirir un
cierre de giro, todas las demás actividades al nivel IRQ del cierre o a niveles inferiores
cesan en ese procesador. Como la conmutación de hilos sucede al nivel de Despacho, un
hilo que sostiene un cierre de giro nunca es expropiado (el IRQL enmascara al mecanismo
de despacho). Esto permite que los hilos que retienen cierres de giro continúen
ejecutándose para que el cierre se libere rápidamente. El núcleo usa los cierres de giro con
mucho cuidado minimizando el número de instrucciones que ejecuta mientras retiene
alguno8.
NT implementa la arquitectura estándar de manejo de interrupciones en dos niveles, típica
de los sistemas operativos de red. Primero, la interrupción es manejada por una ISR muy
corta. Luego el trabajo se completa mediante la ejecución diferida de un Llamada a
Procedimiento Diferido o DPC (“Deferred Procedure Call”). Las ISR pueden ser
interrumpidas por ISR de mayor prioridad. Por su parte, todas las DPC se ejecutan, al nivel
7A partir de Windows 2000 (NT 5.0) la documentación oficial de Microsoft ha eliminado la alusión de que el
núcleo de NT es no expropiable [86][77]. Esto hace suponer que a partir de estas versiones si el núcleo no está
ejecutando código dentro de una sección crítica protegida por cierres de giros (“spinlocks”) puede ser
expropiado. De cualquier modo, en un sistema SMP el hecho de que el núcleo no sea expropiable no garantiza
protección implícita de las regiones críticas contra secciones del núcleo que pudieran estar corriendo en otra
CPU.
8 Debido a que el IRQL es un mecanismo de sincronización efectiva en sistema uniprocesadoes, las funciones
de adquisición y liberación de los cierres de giro en el HAL uniprocesador en realidad no los implementan
sino que simplemente elevan o disminuyen el IRQL.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 41
de prioridad de despacho el cual se encuentra por encima del nivel de prioridad de los hilos
de usuario y del sistema (ver Figura 9). Esto significa que se ejecutan con todas las
interrupciones de hardware habilitadas y con la planificación y los demás DPCs
inhabilitados (todos están al mismo nivel de prioridad). Los DPC se sitúan en cola en este
nivel y se planifican según una disciplina FIFO (“First In - First Out”).
3.2.2 Manejo de Interrupciones en Linux
Al igual que los sistemas Unix tradicionales, las versiones del núcleo de Linux (previas a la
versión 2.6) son no expropiables y también se pueden dividir en dos mitades: una mitad
no dirigida por interrupción (“non-interrupt half”) que es activada de forma procedural
por las llamadas al sistema (que se corresponde con el “top half” de BCD) y la otra mitad
dirigida por interrupción (“interrupt half”) que contiene el código que se ejecuta como
parte de las peticiones de interrupción (y se corresponde con el “bottom half” de BSD).
Igual que en los sistemas Unix clásicos, ninguna interrupción que se reciba mientras un
proceso (o hilo) está ejecutando el código de un servicio del núcleo, provoca una
replanificación de forma directa; en su lugar, se activa la bandera del núcleo need_resched
para solicitarle al núcleo que ejecute el planificador luego de que se haya completado la
llamada al sistema y se esté por devolver el control al modo usuario. Los procesos (o hilos)
utilizan el mismo mecanismo de sincronización con eventos basado en el esquema de
dormirse/despertarse. La sincronización entre el código de la mitad no dirigida por
interrupción y el código de las ISRs se realiza de igual modo mediante la inhabilitación
temporal de las interrupciones durante el acceso a las estructuras de datos compartidas.
Al igual que otros sistemas operativos de red, Linux implementa una arquitectura estándar
de manejo de interrupciones en dos niveles dividiendo el servicio a las interrupciones en
dos secciones: la mitad superior (“Top half”) constituida por la ISR que recibe la
interrupción de hardware y la mitad inferior (“Bottom half”) que hace el grueso del
procesamiento de la petición de forma diferida con todas las interrupciones habilitadas
[101].
La arquitectura de bottom half original se mantuvo sin modificaciones hasta la versión
Linux 2.2. Sin embargo, debido a que el diseño original de Linux se hizo para máquinas
con una sola CPU, esta arquitectura de bottom half se convirtió en un cuello de botella en
arquitecturas con múltiples CPU. El problema era que aunque cada una de las CPU podía
manejar una interrupción (“top half”) a la vez, la capa de bottom half era de simple hilo, de
modo que el procesamiento diferido por todas las ISRs no se podía distribuir entre todas las
CPUs. En consecuencia, para la versión 2.3 se introdujo el soporte de multiprocesamiento
simétrico o SMP (“Symmetric Multiprocessors”) en los bottom halves. Esto se llevó a cabo
reemplazando los bottom halves originales con los denominados “softirq” y “tasklets”.
Una softirq representa una petición para que una función específica se ejecute en algún
instante futuro. Si el mismo tipo de softirq se solicita múltiples veces entonces las
invocaciones de esta se pueden ejecutar de forma concurrente en múltiples procesadores.
Por el contrario, diferentes tasklets pueden ejecutarse simultáneamente en múltiples CPUs,
pero las invocaciones de la misma tasklet son serializadas con respecto a si mismas. Por
razones de compatibilidad, los bottom halves del viejo estilo se volvieron a implementar
Luis Eduardo Leyva del Foyo 42
utilizando un conjunto de tasklets que se ejecutaban reteniendo un cierre de giro
(“spinlock”) global dedicado de modo que cuando uno se está ejecutando en alguna CPU,
ningún otro se puede ejecutar en alguna otra CPU.
Aunque el diseño anterior preservó la compatibilidad con los manejadores de dispositivos
legados, todavía le imponía una fuerte restricción al desempeño de Linux 2.4 en sistemas
multiprocesador. Para la versión Linux 2.5 los bottom halves del viejo estilo fueron
eliminados y todo el código que lo usaba se modificó para usar ya sea softirqs o tasklets.
Actualmente el término “Bottom Half” se usa para referirse a cualquiera de los código
diferibles (sea softirq o un tasklet).
En Linux 2.6 se introdujo otro esquema para planificación de funciones diferidas al que se
le denomina colas de trabajo (“workqueues”) y que como diferencias más importantes con
las funciones diferibles antes mencionadas se ejecutan en el contexto de hilos del núcleo.
La Figura 10 muestra un resumen de estos mecanismos de ejecución diferida de Linux.
Bottom Half Estado Comentario
BH Eliminado en 2.5 Su ejecución está globalmente serializada.
Task queues Eliminado en 2.5
Softirq Disponible desde 2.3 Pueden ejecutarse en varias CPUs a la vez,
incluso si son del mismo tipo.
Tasklet Disponible desde 2.3 Las de diferentes tipos se pueden ejecutar
concurrentemente, pero las del mismo tipo no.
Work queues Disponible desde 2.5
Figura 10. Niveles de protección de Interrupción
3.2.3 Problema del Encierro de Recepción (“Receive Livelock”) y soluciones
propuestas
Un problema potencial con la arquitectura de interrupciones en dos niveles es que, como las
interrupciones del dispositivo se habilitan antes de finalizar su procesamiento (con el
procesamiento diferido pendiente) no tienen protección contra la posibilidad de que el
dispositivo genere peticiones de interrupción a una tasa sostenida superior a la capacidad de
procesamiento. Esta situación provoca que, bajo cargas de trabajo extremadamente
elevadas, pueda presentarse lo que se conoce como encierro de recepción (“receive
livelock”) [66] o condición en la cual el sistema de cómputo se ve abrumado
(“overwhelmed”) por la llegada de interrupciones y durante períodos de tiempos
extremadamente largos gasta la mayor parte o todo su tiempo procesando las interrupciones
(dejando en inanición los hilos de las aplicaciones). En casos extremos, el procesamiento
diferido al IPL bajo nunca termina antes de que se reciba la siguiente interrupción,
entregando más datos y requiriendo más procesamiento al IPL bajo. El empleo de buffers
puede absorber pequeñas ráfagas de datos recibidos, pero en última instancia el espacio se
puede agotar y los datos tienen que ser desechados. Si esta situación continua entonces no
se hará trabajo útil porque el sistema gasta todo su tiempo recibiendo datos sólo para
desecharlos más tarde.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 43
Se han propuestos varias técnicas para enfrentar este problema. Todas ellas se apoyan en
reducir la tasa a la cual pueden ocurrir las interrupciones con el propósito de evitar la
llegada del encierro de recepción; si el sistema está sometido a una sobrecarga
(“overloaded”) entonces tiene sentido desechar los paquetes no procesados en el
dispositivo/interfaz antes de que se invierta esfuerzo en el procesamiento parcial. Un
enfoque simplista es inhabilitar las interrupciones provenientes de un dispositivo específico
cuando los datos provenientes del mismo ocupan más de algún umbral en los buffers
internos. Un segundo enfoque, propuesto en [66] por Mogul y Ramakrishnan, consiste en
reducir el tamaño del manejador de interrupción a un mínimo absoluto, sólo una
notificación de que ha sucedido un evento, y utilizar este para disparar la encuesta
(“polling”). Tales interrupciones son idempotentes y pueden ser enmascaradas desde el
instante entre la entrega de la primera desde el dispositivo y encuestar el estado del
dispositivo.
3.2.4 Dificultades para aplicaciones de tiempo real y modificaciones propuestas
La arquitectura de procesamiento de interrupciones en dos niveles propia de los sistemas
operativos de red (VMS, BSD 4.2+, NT o Linux) consigue descargar el procesamiento de
interrupción de los manejadores de interrupción hacia una actividad planificada de forma
independiente (AST en VMS, interrupción de software en BSD 4.2+, DPC en NT y mitad
inferior – “bottom half” – en Linux). Al acortar las ISRs, el sistema es capaz de responder a
las interrupciones subsecuentes más pronto, reduciendo la latencia de interrupción en el
peor caso. Sin embargo, todas estas variantes de manejadores de interrupción diferidos se
planifican antes que todas las tareas de usuario. Por tanto, todo el procesamiento de
interrupciones en estos sistemas se ejecuta efectivamente a una mayor prioridad que todas
las tareas de usuario, incluyendo los procesos de tiempo real. Para las aplicaciones de
usuario críticas en tiempo que están impedidas de ejecutarse, hay poco beneficio en el
hecho de que el trabajo se esté haciendo en manejadores diferidos en vez de en las ISRs
propiamente. Varios investigadores ha propuestos distintas adecuaciones de esta
arquitectura para enfrentar mejor los requerimientos de aplicaciones sensibles al tiempo
(por ejemplo [40] y [105]).
Uno de los problemas de este diseño es el denominado tiempo robado (“stolen-time”) a las
aplicaciones por el procesamiento de interrupciones, principalmente por los manejadores de
procesamiento diferido. Este tiempo está completamente fuera del control del planificador
del sistema y fluctúa grandemente de modo que introduce una perturbación al planificador
de procesos (o hilos) que afecta significativamente su capacidad para hacer cumplir la
política de distribución del tiempo de la CPU entre las aplicaciones de usuario.
En [40] se propuso e implementó un esquema de planificación de los manejadores diferidos
(“botton half”) de Linux 2.4. Este consiste en supervisar el tiempo consumido por los
manejadores diferidos y detener las subsiguientes ejecuciones de los mismos una vez que
este tiempo ha sobrepasado un valor de umbral. Los manejadores pendientes son
pospuestos hasta el siguiente instante en que el núcleo proceda a la ejecución de los
mismos. De esta forma, el exceso de carga de trabajo por encima del tiempo de umbral
establecido se procesa cuando las peticiones de manejadores diferidos están por debajo del
tiempo de umbral. Un aspecto interesante de este esquema es que el valor de umbral no es
Luis Eduardo Leyva del Foyo 44
fijo sino que se obtiene dinámicamente usando una estimación basada en el tiempo
previamente consumido por el procesamiento diferido. Esta característica de adaptación del
umbral a la carga de E/S consigue evitar variaciones bruscas del tiempo consumido
(robado) por los manejadores de procesamiento diferido logrando estabilizar el tiempo de
ejecución de los procesos de usuario; todo ello sin introducir una demora en el servicio a
los paquetes de red. Además, el método propuesto no necesita modificar el mecanismo de
planificación o la arquitectura del subsistema de red.
Más recientemente en [105] Zhang y West propusieron e implementaron una modificación
a la arquitectura de Linux 2.6 que añade un planificador de los manejadores de interrupción
diferibles (conocidos como bottom halves, softirqs y tasklet – ver sección 3.2.2) luego de la
ejecución de la ISR de primer nivel. Este planificador hace una preedición de la prioridad
del proceso que hizo la solicitud (y que fué beneficiado por la interrupción) para determinar
de forma más precisa cuando planificar la ejecución del manejador diferido. Además, luego
de que se ejecuta el manejador diferido se añade un componente que contabiliza el tiempo
de ejecución de los manejadores de interrupción y se los carga al proceso apropiado.
3.3 Manejo de Interrupciones como Hilos
Una alternativa al esquema de manejo de interrupciones en dos niveles discutido en la
sección 3.2 es el tratamiento de las interrupciones dentro de actividades concurrentes
asíncronas (hilos, tareas o procesos) dedicadas. La idea general de este esquema consiste en
que el núcleo del sistema operativo se encarga de situar un manejador de interrupción de
bajo nivel genérico el cual hace lo necesario para activar a una actividad asíncrona (hilo,
tarea o proceso) que se ocupa de dar el tratamiento específico de la interrupción. Aunque la
idea general es la misma, la motivación y los detalles de implementación permiten
identificar dos variaciones: Señales de interrupciones como eventos de comunicación entre
procesos o IPC (“Inter-process comunication”) propia de los sistemas con arquitectura de
micro-núcleo; e Interrupciones como hilos del núcleo. A su vez, en este último se presentan
dos variaciones ejemplificadas por el modelo de interrupciones como hilos de Solaris 2.0
(ver sección 3.3.2) y el modelo de interrupciones como hilos de los sistemas de tiempo real
(LynxOS o Linux de Tiempo Real – ver sección 3.3.3)
3.3.1 Interrupciones como IPC (arquitectura de micronúcleo)
Un micro-núcleo (“micro-kernel”) es un pequeño núcleo de un sistema operativo que
implementa las funciones fundamentales que sirven de base para extensiones modulares y
transportables que implementan los servicios menos esenciales del sistema. Típicamente el
micro-núcleo suministra la abstracción de tareas o procesos planificables y el mecanismo
de comunicación entre éstos basado en mensajes. Servicios como son el sistema de
archivos, sistema de ventanas, servicios de seguridad y otros se implementan como
componentes encima del micro-núcleo y se comunican unos con los otros mediante el
empleo de los servicios IPC que suministra el micro-núcleo. Es interesante que los
conceptos que subyacen en la arquitectura de micro-núcleo (y la señalización de
interrupciones a través de IPC) fueron introducidos por vez primera en 1969 con el sistema
multiprogramado del RC 4000 [13][14] mucho antes de la introducción del término microAdministración
de Interrupciones en Sistemas Operativos de Tiempo Real 45
núcleo como tal. Este sistema fue diseñado por Brinch-Hansen para la computadora RC
4000 fabricada en Dinamarca por Regnecentralen..
El núcleo del sistema de la RC 4000 suministró los mecanismos básicos para crear un árbol
de procesos concurrentes que (aunque podían compartir memoria) interactuaban entre si
mediante un mecanismo de comunicación basado en mensajes según un protocolo de
petición y respuesta entre dos procesos. Según el propio Brinch Hansen, la elección de este
esquema estuvo condicionada por una decisión temprana de tratar a los dispositivos de E/S
como procesos, que reciben comandos de E/S como mensajes y devuelven acuses de
recibos o respuestas [15]. Los manejadores de dispositivos se codificaban de forma tal que
convertían las interrupciones del dispositivo y los registros en mensajes. Así, un proceso
escribiría a una Terminal enviándole a dicha Terminal un mensaje. El manejador de
dispositivo recibiría el mensaje y sacaría el carácter a la Terminal. Un carácter de entrada
interrumpiría al sistema y transferiría el control al manejador de dispositivo. El manejador
de dispositivo crearía un mensaje a partir del carácter de entrada y lo enviaría al que está
esperando por él.
El sistema Mach [3], se basó en los mismos principios, acuñando el término micro-núcleo
(“microkernel”). Otro micro-núcleo contemporáneo con Mach fue Chorus [75], ambos
fueron críticos para la evaluación en el “mundo real” y la investigación del diseño de
micro-núcleo. Mach, Chorus y otros muchos seguidores de finales de la década de 1980 son
exponentes de lo que se conoció como primera generación de micro-núcleos.
3.3.1.1 Manejo de interrupciones a nivel de usuario
A tono con la filosofía de micro-núcleo es la implementación de todos los manejadores de
dispositivo (“device drivers”) como servidores a nivel de usuario fuera del núcleo. Esto
tiene la ventaja de que los manejadores de dispositivos pueden ser reemplazados,
eliminados, o añadidos dinámicamente – sin enlazar un nuevo núcleo e iniciar el sistema.
Así los manejadores pueden distribuirse a los usuarios finales independientemente del
núcleo. Motivados por esto, los micro-núcleos se ven en la necesidad de suministrar
mecanismos que les permitan a los manejadores de dispositivo el acceso a los dispositivos y
la implementación de manejadores de interrupciones a nivel de usuario.
La idea más natural de permitir manejadores de interrupción a nivel de usuario en un
micro-núcleo es interpretando las interrupciones de hardware como mensajes de
comunicación entre procesos o IPC (“inter-process communication”) [57]. El micro-núcleo
captura todas las interrupciones pero no se involucra en el manejo específico del dispositivo
(no necesita saber nada de la semántica de la interrupción ni la política de manejo), en su
lugar sólo genera un mensaje para el proceso o hilo de nivel de usuario asociado con la
interrupción (mecanismo). Así, consistente con el principio de separación de mecanismo y
política, el manejo específico de las interrupciones y de la E/S a los dispositivos se hace
completamente fuera del núcleo en el contexto de una tarea hilo o proceso de la forma
ilustrada en la Figura 11.
La transformación de las interrupciones en mensajes destinados al hilo o proceso asociado,
tiene la ventaja adicional de que los manejadores de dispositivo se benefician del empleo de
Luis Eduardo Leyva del Foyo 46
los mecanismos suministrados por el micro-núcleo tales como hilos, espacios de
direcciones y fundamentalmente los mecanismos de comunicación y sincronización entre
hilos. Como consecuencia la sincronización de interrupciones se resuelve usando la
sincronización de hilos ordinaria sin necesidad de algún mecanismo especial.
Driver thread:
do
wait for (msg, sender) ;
if sender = mi interrupción de hardware
then read/write i/o ports ;
limpia la interrupción de hardware
else . . .
while (TRUE);
Figura 11. Interrupciones como IPC
3.3.2 Modelo de manejo de interrupciones como Hilos del Núcleo en Solaris 2.0.
Sun Microsystems introdujo soporte de hilos en el núcleo en su sistema operativo Solaris
2.x (SunOS 5.0) [31]. En Solaris un hilo de núcleo es la entidad fundamental que es
planificada y despachada en las CPUs del sistema. Los hilos de núcleo son muy ligeros,
sólo poseen una pequeña estructura de datos y una pila. La conmutación entre hilos de
núcleo es muy ligera ya que no requiere el cambio de espacio de direcciones de memoria
virtual. Los hilos de núcleo (y el núcleo de Solaris) son completamente expropiables (los
detalles de la arquitectura de Solaris pueden verse en [63]).
Solaris reemplaza el modelo tradicional de interrupción y sincronización con un esquema
en el que las interrupciones son manejadas como hilos del núcleo. Estos hilos de
interrupción pueden crearse dinámicamente y se les asigna una mayor prioridad que a
todos los demás tipos de hilos. Ellos usan las mismas primitivas de sincronización que los
demás hilos y por tanto se pueden bloquear si necesitan un recurso retenido por otro hilo.
En consecuencia, el núcleo no necesita utilizar el IPL del procesador para protegerse de las
interrupciones. El núcleo bloquea las interrupciones sólo en unas pocas situaciones
excepcionales [45].
Aunque la creación de hilos del núcleo es relativamente ligera, todavía es demasiado
costoso crear un nuevo hilo para cada interrupción. El núcleo mantiene un banco de hilos
de interrupción, preasignados y parcialmente inicializados. Por omisión, este banco
contiene un hilo por nivel de interrupción por cada CPU, más un único hilo en todo el
sistema para el reloj.
El mecanismo es el siguiente: cuando llega la interrupción, un manejador de interrupción
dentro del núcleo eleva el IPL para evitar interrupciones adicionales del mismo nivel o de
nivel inferior. Luego asigna un hilo de interrupción desde el banco y conmuta el contexto
al mismo. Mientras se ejecuta el hilo de interrupción, el hilo interrumpido está clavado
(“pinned”), lo que significa que no puede ejecutarse en otra CPU. Cuando el hilo de
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 47
interrupción devuelve el control, se conmuta el contexto nuevamente al hilo interrumpido,
el cuál reanuda la ejecución.
Con el propósito de disminuir la sobrecarga de la conmutación de contexto hacia el hilo de
interrupción, este se ejecuta sin ser inicializado completamente. Esto significa que no es un
hilo “con todas las de la ley” y no puede ser desplanificado. La inicialización se completa
sólo si el hilo se bloquea. En este instante, se desclava el hilo interrumpido y se salva el
estado completo del hilo de interrupción convirtiéndose en un hilo capaz de ser planificado
como cualquier otro. Posteriormente, se devuelve el control al hilo previamente
interrumpido. De esta forma, la sobrecarga de una inicialización completa del hilo se
restringe a los casos en los que el hilo de interrupción se debe bloquear.
La implementación de las interrupciones como hilos añade un costo operativo al manejo de
las interrupciones. Sin embargo, se evita la necesidad de manipular el IPL del procesador
para bloquear las interrupciones en cada operación sobre un objeto de sincronización (y
dejarlas bloqueadas mientras se está dentro de una sección crítica del núcleo)9. Debido a
que las operaciones de sincronización son mucho más frecuentes que las interrupciones, el
resultado es una mejora del desempeño, siempre y cuando las interrupciones no se bloqueen
demasiado frecuentemente. En la práctica, menos del 0.5% de las interrupciones se
bloquean. El trabajo de convertir una interrupción en un hilo “real” se realiza sólo cuando
existe contención por cierre. El compromiso aquí es que el hilo interrumpido queda clavado
imposibilitando su ejecución (incluso en otra CPU) hasta que el manejador de interrupción
termine o se bloquee lo cual puede introducir una inversión de prioridad temporal. Sin
embargo, este esquema ayuda a mejorar el desempeño y reducir la latencia de interrupción,
particularmente en el caso de multiprocesadores.
Es importante destacar que la optimización de despachar al hilo de interrupción de forma
inmediata (sin pasar por la trayectoria normal del planificador) es posible en Solaris por dos
razones:
(1) los hilos de interrupción poseen una prioridad mayor que el resto de los hilos en el
sistema la cual además es la que se corresponde con la prioridad de la interrupción de
hardware. Esto garantiza que siempre que se recibe una interrupción no puede haber
otro hilo (no asociado a interrupción) de mayor prioridad listo para ser ejecutado.
(2) porque su núcleo es completamente expropiable; o sea, que permite que ocurra una
conmutación de hilo en cualquier momento. Este hecho es lo que le permite despachar
la ejecución del hilo de interrupción en el mismo instante en que se produce la
interrupción (sin necesidad de tener que esperar a que el hilo actual abandone la
ejecución de alguna sección de código dentro del núcleo).
9 En [45] se documenta que la carga operativa adicional de recibir una interrupción (respecto al método
tradicional) es de unas 40 instrucciones SPARC. El ahorro en la ruta cierre/apertura del mutex es de unas 12
instrucciones las cuales elevan y disminuyen la prioridad de interrupción del procesador. Debe considerarse
además que el SPARC tiene integrado dentro de la CPU la lógica para controlar el nivel de interrupción del
procesador integrado. Los procesadores que usan controladores de interrupción externos (como el Pentium)
pudieran probablemente incurrir en un gasto mayor.
Luis Eduardo Leyva del Foyo 48
Obsérvese que en un sistema operativo no expropiable la replanificación sólo puede tener
lugar en momentos específicos en que el núcleo está en un estado consistente. En este caso
si se transfiriere el control de forma inmediata al manejador de interrupción (como sucede
en Solaris) entonces dicho manejador no se podría bloquear ya que la interrupción se pudo
haber producido en cualquier instante, incluso en momentos en que el núcleo no se
encuentra en un estado consistente. En esta situación el bloqueo provocará que se entre al
núcleo y este haga una replanificación en un momento inoportuno provocando el colapso
del sistema. En consecuencia, en sistemas con núcleos no expropiables, los hilos de
interrupción tienen que esperar porque el hilo interrumpido termine su trayectoria de
ejecución dentro del núcleo, por lo que se afecta significativamente la latencia de
interrupción.
3.3.3 Interrupciones manejadas como hilos en los sistemas Linux para Tiempo Real
Motivados por la necesidad de hacer que el núcleo de Linux fuese más sensible
(“responsive”) a los eventos externos de modo que fuese adecuado para aplicaciones con
requerimientos de tiempo, muchos trabajos le han realizado modificaciones para
introducirle el tratamiento de interrupciones (exceptuando la ISR del Reloj) en el contexto
de hilos del núcleo (Manas Saksena – TimeSys. – [79], Steven-Thorsten Dietrich et. al. –
Montavista – [29], Heursch et. al [36] y Yang et. al. [103]). Estas modificaciones han
tenido el propósito de reducir la latencia de expropiación, la cual puede ser muy elevada en
Linux (superior a los 100 ms [35][102]).
Estos trabajos estuvieron precedidos por los primeros enfoques para introducir la
expropiación al núcleo de Linux: los parches de expropiación [5][96] y los parches de baja
latencia [104]. Las primeras implementaciones de estos parches protegían las secciones
críticas dentro del núcleo mediante cierres de expropiación (“preemption locks”) que
inhabilitaban la expropiación durante las mismas [5]. El siguiente paso fue sustituir los
cierres de expropiación por mutexes de modo que la expropiación fuese posible incluso
mientras el núcleo está dentro de una sección crítica [96]. Estas técnicas lograron reducir
significativamente la latencia de expropiación con respecto al núcleo de Linux
convencional; sin embargo todavía no logran obtener valores suficientemente bajos (ver
[26][102][2]). La razón de ello es que con estas técnicas no es posible la expropiación
mientras se está ejecutando una ISR o incluso los manejadores de segundo nivel.
Un problema aún mayor es que, a pesar de que la arquitectura de interrupciones en dos
niveles (sección 3.2.2 ) permite posponer el grueso del procesamiento de una interrupción a
los manejadores diferidos. Todavía los tiempos de ejecución de los manejadores de primer
nivel o ISRs difieren significativamente de una interrupción a otra. Como las ISRs se
ejecutan con las interrupciones inhabilitadas todavía se hace muy difícil predecir el tiempo
máximo durante el cual las interrupciones están inhabilitadas.
La solución a estas dificultades consistió en ejecutar los manejadores de interrupción en su
propio contexto de hilos del núcleo. Bajo este esquema, todas las interrupciones (excepto la
del temporizador) se dirigen hacia un manejador de bajo nivel en el núcleo cuyo único
propósito es despertar a un hilo del núcleo correspondiente a la interrupción que
previamente está durmiendo. Este hilo puede entonces ser ejecutado posteriormente con
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 49
todas las interrupciones habilitadas y bajo el control del planificador de hilos. Los hilos del
núcleo dedicados al manejo de interrupción se pueden planificar en la clase de planificación
de tiempo real (SCHED_FIFO) permitiendo además asignarles prioridades inferiores a las
de los hilos convencionales de tiempo real.
Este esquema de interrupciones manejadas como hilos logra reducir la latencia de
expropiación de tres formas:
1) Al permitir que los manejadores de interrupción se duerman, es posible reemplazar los
cierres combinados de cierres de giro e interrupciones convencionales de Linux por
mutexes que implementan el protocolo de herencia de prioridad permitiendo la
expropiación de estas regiones críticas.
2) Como los hilos del núcleo destinados al manejo de interrupciones son expropiables, si
llega una interrupción de mayor prioridad mientras se está ejecutando el hilo del núcleo,
el hilo de ISR con mayor prioridad puede expropiar al de menor prioridad.
3) Todas las interrupciones ejecutan una ISR común que da el mismo servicio y consume
el mismo tiempo de ejecución para todas las interrupciones. De este modo, se puede
restringir la latencia de interrupción a un período fijo y corto.
La ejecución de los manejadores de interrupción como hilos en todas estas versiones de
Linux posee varias diferencias significativas con respecto a la realización en Solaris.
1) En Solaris 2.x+, las prioridades de los hilos de interrupción se corresponden con las
mismas prioridades de las interrupciones de hardware sólo que mapeadas a la parte más
alta (de mayor prioridad) del espacio de prioridades de los hilos convencionales
(sección 3.3.2). En Linux, los hilos de interrupción se ejecutan con interrupciones
habilitadas a cualquier prioridad que se le asigne.
2) En Linux, la ISR general que se ejecuta cuando ocurren las interrupciones no esquiva la
trayectoria de planificación normal del núcleo (como ocurre en Solaris 2.x+ – sección
3.3.2), sino que simplemente despierta al hilo de interrupción correspondiente el cual
será entonces planificado del mismo modo que los demás hilos.
3.4 Tratamiento de Interrupciones en sistemas Embebidos y de Tiempo real
Las aplicaciones de cómputo tradicional propias de los sistemas de tiempo compartido
aceptan una entrada, la procesan, y producen algún tipo de salida. A este tipo de sistemas
de cómputo se les ha denominado sistemas transformacionales (“transformational
systems”) [34]. A diferencia de estos, la mayoría de los sistemas embebidos y de tiempo
real se caracterizan por ser sistemas reactivos (“reactive systems”) [34] o dirigidos por
eventos (“event-driven”) que pasan una gran parte del tiempo en un estado de espera por
eventos o estímulos ante los cuales reaccionar. Una vez terminadas las acciones de manejo
de estos eventos (reacción), tales sistemas regresan al estado de espera por el siguiente
evento [81].
Los estímulos primarios son generados por el hardware a partir de eventos internos
(provenientes del propio sistema de cómputo) o externos (provenientes del entorno
exterior) y comunicados al software del sistema mediante el mecanismo de interrupciones
Luis Eduardo Leyva del Foyo 50
de hardware. El estimulo primario interno más común es el tic del reloj del sistema (que
marca el paso del tiempo). Los estímulos primarios externos comprenden una amplia
variedad dependiendo de la aplicación de que se trate. Ejemplos de este último tipo son la
depresión de un botón (o tecla), un clic del ratón, la llegada de un paquete de datos, etc.
Al reconocer un evento, estos sistemas reaccionan llevando a cabo el cómputo apropiado
para manejarlo. Esta reacción puede ser la emisión una acción de respuesta al entorno
exterior (mediante la manipulación del hardware de salida del sistema) o la generación de
otros eventos secundarios o de software. Ejemplo de eventos secundarios de software son
el vencimiento de un temporizador (“timeout”) lógico establecido por el software, la
emisión de una solicitud de interrupción de software o la activación (arribo a la cola de
tareas listas) de una tarea (hilo o proceso) que previamente no era ejecutable. Estos eventos
de software provocan la ejecución de otros elementos de software. Por ejemplo, una
petición de interrupción de software provoca la ejecución de un manejador de interrupción;
el vencimiento de un temporizador provoca la ejecución de un manejador de vencimiento
de tiempo (“timeout handler”) y la activación de una tarea, trae como consecuencia la
ejecución de la misma.
No importa que estos eventos sean internos o externos, una característica importante de los
mismos es la impredecibilidad de su ocurrencia. La impredecibilidad de los eventos
primarios se hace más evidente dado que, en el caso de los eventos externos, son emitidos
fuera del control del software. En el caso de los eventos de software internos, un análisis
ingenuo pudiera llevar a pensar que al ser generados por el propio software, tienen un
carácter predecible. Sin embargo, aunque es cierto que son emitidos por el software del
sistema, este lo hace sólo en respuesta a los eventos primarios (que están fuera de su
control) lo cual lo convierte en impredecibles. Por ejemplo, los instantes en que se activa
(desbloquea) o se desactiva un tarea a cargo de procesar los mensajes provenientes de la red
dependen de la tasa con que estos mensajes se reciben y la longitud de los mismos, aspectos
ambos fuera del control del sistema receptor.
3.4.1 Planificación del Tratamiento de los eventos
Un aspecto importante del entorno exterior es que este está compuesto por una variedad de
elementos del mundo real (por ejemplo, servo mecanismos, actuadores, magnitudes físicas
que caracterizan el estado de algún proceso externo controlado obtenidas a través de
sensores) que operan o evolucionan en paralelo e independientemente los unos de los otros
(y del sistema de cómputo). En consecuencia, el software encargado de interactuar con
estos sistemas es concurrente por naturaleza. En cada instante pueden existir múltiples
actividades de cómputo a ser ejecutadas. El núcleo del sistema operativo de tiempo real
utiliza el mecanismo de multiprogramación para entrelazar la ejecución de las mismas
según un algoritmo de planificación.
La ejecución de los elementos de software encargados de manejar los distintos eventos que
suceden en el sistema (posiblemente de forma simultánea) consume recursos del sistema de
cómputo (en un sistema de tiempo real, el tiempo de CPU es el recurso más importante).
Debido a que estos recursos de cómputo son limitados y además debido al conflicto
potencial en las demandas y el acceso a los mismos por parte de las distintas actividades de
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 51
cómputo, es posible que en el preciso instante en que se produjo el evento no estén
disponibles los recursos necesarios para la ejecución del software encargado de su manejo
(por ejemplo el tiempo de CPU se tiene que dedicar a ejecutar otra actividad cuyo plazo de
respuesta es más urgente en ese instante). Como consecuencia, las actividades de software
no pueden ser ejecutadas de forma inmediata a la ocurrencia del evento correspondiente;
sino que, es necesario diferir su ejecución según algún algoritmo de planificación que
permita satisfacer los requerimientos de todas las actividades de cómputo bajo las
restricciones de recursos del sistema.
Dado que en los sistemas de tiempo real el recurso más importante es el tiempo, el
algoritmo de planificación debe ser tal que posibilite el establecimiento de garantías del
cumplimiento de los plazos de respuesta a los eventos externos. Esto se consigue mediante
las pruebas de factibilidad de planificación (“schedulability”) propias del algoritmo (ver
sección 2.3). Como consecuencia, un algoritmo de planificación de tiempo real cumple la
función de asignar el tiempo de cómputo de la CPU de forma tal que (bajo ciertas
suposiciones de diseño y determinada caracterización del sistema) sea posible conocer por
anticipado (o sea predecir) los tiempos de respuesta a eventos cuyo instante o patrón de
llegada no se conoce con exactitud (o sea son impredecibles). En otras palabras, un
planificador de tiempo real transforma las demandas asíncronas no predecibles en
procesamiento síncrono planificado (según criterios preestablecidos) y predecibles10. En
este sentido podemos concebir la planificación de tiempo real como un mecanismo que le
“introduce” la predecibilidad al sistema y que, de alguna forma, funciona como una barrera
(“firewall”) a la impredecibilidad.
3.4.2 Entidades Planificables vs. Entidades No planifcables
A las actividades de cómputo que se ejecutan bajo el control del planificador de tiempo real
se les denomina entidades planificables (“schedulable entities”) y en su conjunto
constituyen el dominio de predecibilidad del sistema. Idealmente (para poder establecer
garantías de cumplimiento de los plazos), en un sistema de tiempo real, el planificador de
tiempo real debería planificar todas las actividades dentro del sistema; sin embargo, en los
sistemas reales algunas cosas están fuera de su control. Ejemplo de ello son: el servicio a
las interrupciones (ejecución de las ISRs); los accesos directos a memoria o DMA; los
manejadores de vencimiento de tiempos (“timeout”) y algunas otras actividades que por
alguna razón son ejecutadas con una “prioridad” mayor que el propio planificador del
sistema11. Todas estas actividades utilizan una fracción de los recursos del sistema (como
tiempo de CPU) pero no están controladas por el planificador de tiempo real por lo que se
les denominan entidades no planificables (“non-schedulable entities”). Estas entidades no
planificables le hacen estragos a la secuencia de ejecución preestablecida por el
planificador y en conjunto constituyen un dominio de impredecibilidad lo cual constituye
10 Aquí planificado se entiende como controlado
11 En realidad estas actividades son planificadas por planificadores que poseen precedencia sobre planificador
de tiempo real del núcleo del sistema. Por ejemplo, las actividades de DMA son planificadas por el
controlador del bus del sistema y en muchos esquemas le “roban” tiempo a la CPU principal en los accesos al
bus. Las ISRs son planificadas por el controlador de interrupciones del hardware según sus prioridades de
hardware (como se vio en la sección 2.5.1). Los manejadores de vencimiento de tiempo son planificados por
el manejador de interrupción del tic de reloj del sistema según sus instantes de vencimiento.
Luis Eduardo Leyva del Foyo 52
el anatema de un planificador de tiempo real12. Actualmente, los diseñadores y
programadores de sistemas de tiempo real llevan a cabo grandes esfuerzos para reducir el
número de entidades no planificables y la cantidad de tiempo de CPU que estas consumen
(por ejemplo reducir al mínimo posible el tiempo de ejecución de las ISRs).
3.4.3 Utilización de variaciones de los modelos de Interrupciones tradicionales
A pesar de las diferencias de requerimiento existentes entre los sistemas operativos de
propósito general y los sistemas operativos de tiempo real, la gran mayoría de los núcleos o
sistemas operativos de tiempo real utilizan esquemas de manejo de interrupciones que
cuando más son ligeras adaptaciones de los utilizados en los sistemas de propósito general.
3.4.3.1 Arquitectura simple de Manejador Unificado (o Sincronización por hardware)
El método usado con mayor frecuencia en sistemas operativos pequeños y ligeros consiste
en darle tratamiento a las interrupciones directamente en las ISRs. Este es un método
simple en el cual el sistema operativo no crea ninguna nueva abstracción de alto nivel para
la administración de las interrupciones; sino que, hace uso de las abstracciones brindadas
directamente por el hardware. En este aspecto, esta arquitectura es similar al esquema
utilizado en los Unix tradicionales (ver sección 3.1); sin embargo, existen tres diferencias
fundamentales con respecto a la arquitectura Unix tradicional:
1. En la arquitectura Unix tradicional básicamente las ISRs sólo pueden utilizar un
servicio interno especial del núcleo para desbloquear al proceso en espera del evento
(según el protocolo de dormir/despertar descrito en la sección 3.1.3). En la arquitectura
de manejador unificado, a las ISR les está permitido invocar a cualquier servicio del
sistema operativo para interactuar con las tareas o hilos de aplicación (o solicitar
recursos del sistema) con la única restricción de que este servicio no tenga la
posibilidad de bloquear a la tarea actual (ello podría paralizar el sistema).
2. Dado que en la arquitectura Unix tradicional, las ISRs no invocan servicios del núcleo,
éstos no necesitan inhabilitar las interrupciones para protegerse de las ISRs13. En la
arquitectura de manejador unificado, los servicios invocados dentro de una ISR pueden
modificar estructuras de datos del núcleo. En consecuencia es necesario sincronizar de
forma explícita el acceso a estas estructuras de datos internas. Como el código invocado
desde una ISR no puede bloquearse para esperar a que estas estructuras sean liberadas,
se necesita de algún mecanismo para demorar o postergar el inicio de la ejecución de la
ISR, hasta tanto el recurso esté disponible. Esto se consigue inhabilitando brevemente
las interrupciones mientras algún servicio del sistema está modificando estructuras de
12 Aunque existen técnicas de análisis de factibilidad que le dan cabida a la existencia de entidades no
planificables (ver sección 3.4.5), en el mejor de los casos, su presencia disminuye la eficiencia del
planificador
13 Aunque los servicios del núcleo no necesitan inhabilitar las interrupciones, si lo hacen algunas funciones
internas del núcleo que pueden ser invocadas desde las ISRs como por ejemplo las funciones de
sincronización que implementan el protocolo de dormir despertar. Además, los desarrolladores de
manejadores de dispositivo tienen que inhabilitar las interrupciones para acceder las estructuras de datos
compartidas entre las partes superior e inferior del manejador de dispositivo (ver sección 3.1.4).
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 53
datos críticas dentro del núcleo. Esto evita que cualquier otro programa o ISR haga
cambios no coordinados a los datos críticos que están siendo utilizados por el código en
ejecución.
3. En la arquitectura Unix tradicional, el núcleo es no expropiable (ver sección 3.1.2) lo
que significa que si el código de la ISR provoca que se active una tarea de más
prioridad que la tarea actual mientras la tarea actual está ejecutando algún código del
núcleo, la conmutación de contexto (expropiación) se pospondrá hasta tanto la tarea
actual abandone el código del núcleo. El carácter no expropiable del núcleo evita el
acceso concurrente (en diferentes tareas) de las estructuras de datos internas. En la
arquitectura de manejador unificado el núcleo del sistema operativo es expropiable.
Esto significa que si, producto de una llamada a servicio realizada dentro de una ISR, se
activa una tarea de mayor prioridad, la conmutación de contexto (expropiación) se
producirá inmediatamente a la salida de la ISR Obsérvese que en este caso, no se
requiere que el núcleo sea no expropiable ya que las secciones críticas del núcleo se
protegen de forma explícita mediante la inhabilitación de interrupciones.
HIH
Sincronización de Hardware
No expropiable y
No interrumpible
Tarea
Expropiable e
Interrupible
Cierre de IRQs
Estado
Peticiones de
Interrupción no
Predecibles -IRQs
AltaPrioridad
Baja
Prioridad
Eventos No controlados Eventos Predecibles (impredecibles)
Algoritmo de
Planificación en
Tiempo Real
Planificador/caracteristicas
Planificador
del Núcleo
Hardware de
Interrupción
(PIC)
Dispositivo
de E/S
"Barrera a la impredecibilidad"
Variaciones
Núcleo no expropiable:
La sincronización entre las
interrupciones y las tareas
de usuario se llevan a cabo
mediante el protocolo de
dormir/despertar
(sleep()/wakeup()). Es el
esquema utilizado por los
Unix Tradicionales.
Núcleo expropiable:
Esquema utilizado por los
Sistemas Operativos de
Tiempo Real Simples. La
sincronización entre las
interrupciones y las tareas
de usuario se lleva a cabo
mediante la inhabilitación
de las interrupciones.
Figura 12. Arquitectura de Interrupción Simple Unificada ( con y sin expropiación)
La Figura 12 muestra esquemáticamente esta arquitectura. En el extremo derecho de la
figura se muestran los elementos que intervienen en el manejo de interrupciones en el
sistema. En el extremo superior de la figura se muestra el dispositivo de E/S que genera las
interrupciones (o estímulos primarios). Estas peticiones de interrupción llegan al
controlador de interrupciones del hardware o PIC el cual se encarga de planificarlas de
acuerdo a sus prioridades de hardware. La característica importante aquí es que, tanto la
Luis Eduardo Leyva del Foyo 54
emisión de las interrupciones por los dispositivos como la planificación de esta por parte
del PIC está fuera del control del planificador del núcleo del sistema y por tanto son
eventos no predecibles. En el extremo inferior de la figura aparece el planificador del
núcleo del sistema el cual (en un sistema de tiempo real) ejecuta un algoritmo de
planificación de tiempo real y por tanto los eventos (de software) que este emite
constituyen eventos predecibles. En efecto, el planificador de tiempo real funciona como
una barrera a la impredecibilidad. De este modo, la parte superior de la figura (dispositivos
de E/S y controlador de interrupciones) constituyen el dominio de los eventos asíncronos
no predecibles mientras que la parte inferior (bajo el control del planificador de tiempo
real) constituye el dominio de los eventos síncronos predecibles.
En la parte central de la figura aparecen las distintas entidades de ejecución dentro del
sistema. En la parte central superior se representa la emisión de una interrupción que
provoca la ejecución de la ISR o Manejador de Interrupción de Hardware (HIH –
“Hardware Interrupt Handler”). Este HIH está bajo el control del PIC y por tanto es una
entidad no planificable. En la parte inferior se representan las tareas de la aplicación que se
ejecutan bajo el control del planificador de tiempo real y por tanto son entidades
planificables. El acceso al área de datos común entre tareas e ISRs (estado) se sincroniza
mediante el cierre o inhabilitación de las interrupciones.
Al extremo derecho de la figura se describen dos variaciones de esta arquitectura: La
arquitectura con núcleo expropiable y la arquitectura con núcleo no expropiable (típica de
los sistemas Unix tradicionales). Observe que esta última puede verse como una variación
de la arquitectura unificada en la cual se restringe el número de servicios que se pueden
invocar dentro de la ISR a aquellos necesarios para implementar el protocolo de
dormir/despertar a una tarea de usuario.
La sincronización del acceso a las secciones críticas dentro del núcleo mediante la
inhabilitación de interrupciones tiene el inconveniente de que desactiva la capacidad de
expropiación del sistema lo cual afecta adversamente el desempeño del sistema. Mientras
más tiempo se pase en una sección crítica con las interrupciones desactivadas, mayor la
degradación en la latencia de expropiación del sistema. De hecho, este esquema no brinda
ninguna ventaja significativa con respecto al esquema de núcleo no expropiable de Unix a
no ser que los períodos durante los cuales el sistema operativo inhabilita las interrupciones
sean muy cortos.
A este método se le denomina la “Arquitectura de Interrupción Unificada” [50] porque todo
el procesamiento de la interrupción se lleva a cabo en una única y “unificada” rutina de
servicio de interrupción (ISR) o arquitectura de sincronización por hardware (“hard
synchronization”) [61] ya que la sincronización se consigue mediante la inhabilitación
temporal de las interrupciones de hardware. Algunos Unix (por ejemplo Xinus [21]) y
muchos núcleos comerciales de tiempo real (por ejemplo μC/OS-II [48], ThreadX [49],
RTEMS [69], y la especificación OSEX/VDX [70]) utilizan esta arquitectura.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 55
3.4.3.2 Arquitectura de Manejador Segmentado (o Sincronización por Software)
La idea general de esta arquitectura es dividir explícitamente el código de manejo de una
interrupción en una parte crítica y una parte no crítica (ver Figura 13).
1. La parte crítica se ejecuta dentro del manejador de la interrupción de hardware o HIH
con muy baja latencia y bajo el control del hardware de interrupciones. Esta debería
llevar acabo sólo el procesamiento más crítico en tiempo y no hace uso de ningún
servicio del núcleo. Antes de terminar, el HIH puede solicitar la ejecución de la parte
que no es crítica mediante la solicitud de interrupciones de software.
2. Los Manejadores de Interrupciones de Software o SIH (“Software Interrupt Handlers”)
son planificados por el núcleo o, en algunas arquitecturas por el mecanismo de
interrupciones de software de la misma CPU (lo cual se representa en la parte derecha
de la Figura 13). La ejecución de estos manejadores se aplaza hasta tanto hayan
terminado todos los manejadores de interrupciones de hardware anidados y ocurre antes
de que se active al planificador de tareas (de tiempo real) del núcleo. Por tanto, estos
SIH tienen prioridad sobre los hilos, pero son interrumpibles por los HIH si llegan
nuevas señales de IRQ.
HIH
SIH
Ejecución
Diferida
CPU
Planificador
Prioridad Media
Interrupciones en dos Niveles
Peticiones de
Interrupción no
Predecibles -IRQs
Dispositivo
de E/S
Hardware de
Interrupción
(PIC)
Alta Prioridad
No expropiable y
No interrumpible
No expropiable
e interrumpible
Algoritmo de
Planificación en
Tiempo Real
Baja
Prioridad
Planificador
del Núcleo
Expropiable e
Interrupible
Eventos Predecibles Eventos No controlados (impredecibles)
Cierre de IRQs Cierre de IRQs
de software
Tarea
Estado
Estado
Planificador/caracteristicas
"Barrera a la impredecibilidad"
Variaciones
Núcleo no expropiable:
La sincronización entre los
manejadores de
interrupción de software y
las tareas de usuario se
llevan a cabo mediante el
protocolo de dormir/
despertar. Es el esquema
utilizado por Linux.
Núcleo expropiable:
Esquema utilizado por los
Sistemas Operativos de
Tiempo Real con manejo
en dos niveles. La
sincronización entre las
interrupciones de software
y tareas se lleva a cabo
inhabilitando las
interrupciones de software.
Figura 13. Arquitectura de Interrupción Segmentada ( con y sin expropiación)
Esta arquitectura es muy similar al esquema utilizado en los sistemas operativos de red (ver
sección 3.2) con la diferencia de que muchos de los sistemas operativos de red poseen un
Luis Eduardo Leyva del Foyo 56
núcleo no expropiable y los manejadores de interrupción de segundo nivel están
restringidos a invocar sólo los servicios que implementan el protocolo de dormir/despertar
(por ejemplo el esquema de “top half/bottom half” de Linux). Los sistemas operativos de
tiempo real que utilizan este esquema poseen núcleos expropiables que sincronizan el
acceso a sus estructuras internas mediante la inhabilitación temporal de la ejecución y los
manejadores de segundo nivel. Además, los manejadores de segundo nivel pueden invocar
cualquier servicio del núcleo no bloqueante.
Como ya se analizó en la sección 3.2, la arquitectura segmentada consigue reducir la
latencia de interrupción mediante la reducción (o eliminación) de la necesidad de inhabilitar
las interrupciones y la reducción de la duración de los manejadores de interrupción de
primer nivel. Sin embargo, es importante destacar que, al igual que cualquier otra, esta
arquitectura tiene que impedir el acceso concurrente a las estructuras de datos internas del
núcleo. En consecuencia, aunque logran minimizar la latencia de interrupción evitando
proteger sus secciones críticas mediante la inhabilitación de interrupciones, en su lugar lo
hacen “demorando” o “inhabilitando” la invocación al planificador (y la conmutación de las
tareas de aplicación) con lo cual mantienen una latencia de expropiación. En consecuencia,
esta arquitectura logra minimizar la latencia de interrupción pero no así la latencia de
expropiación que sigue ejerciendo un impacto negativo en el desempeño del sistema.
Además, como se aprecia en la Figura 13, los manejadores de interrupciones de software
siguen siendo entidades no planificables fuera del control del planificador de tiempo real.
El resultado de esto es que esta arquitectura sólo consigue disminuir la latencia de
interrupción (y como se dijo antes no la de expropiación) sin embargo, no introduce
ninguna mejora a la predecibilidad del sistema (ver sección 3.2.4).
Esta arquitectura de manejador segmentado es utilizada por muchos sistemas operativos
embebidos y de tiempo real. Ejemplos de estos junto con la denominación que dan a cada
uno de los niveles son: ISR/Rutina de Servicio Diferida – ISR/DSR o “deferred service
routine” en eCos [65]; Prólogo/Epílogo – “Prologue/Epilogues” – en PEACE [82] y PURE
[83]; ISR/Rutina de Servicio de Enlace – ISR/LSR o “Link Sevice Routine” en smx[67];
ISR/Llamada a función Demorada – ISR/DFC o “Delayed Function Call” – en Symbian
OS [71].
3.4.3.3 Manejo de Interrupciones a nivel de Hilos en sistemas de Tiempo Real
Con el propósito de disminuir la interferencia provocada por las interrupciones, la mayoría
de los núcleos de tiempo real modernos realizan el segundo nivel de procesamiento de las
interrupciones en una Tarea de Servicio de Interrupción o IST (“Interrupt Service Task”)
según se muestra en la Figura 14.
Se mantiene una pequeña ISR (denotada como HIH en la Figura 14) que lleva a cabo el
procesamiento mínimo necesario para evitar la pérdida de datos y ejecuta un servicio
especial suministrado por el núcleo que permite activar a una IST que se encuentra
esperando mediante la ejecución del servicio de espera complementario. Esta IST se
encarga entonces de llevar a cabo el servicio adicional que necesite la interrupción. Una vez
activada, esta tarea se ejecutará (igual que cualquier otra) bajo el control del planificador
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 57
del núcleo y a una prioridad acorde con los requerimientos de la aplicación. ART [98][99],
HARTIK [1] [19] [20], SPRING [89], Windows CE 3+ [33], Nemesis [53], QNX [37],
Timesys Linux [96] son ejemplos de sistemas que utilizan esta estrategia de procesamiento.
Aunque esta estrategia consigue minimizar la perturbación producida por las ISRs la
ejecución de las mismas todavía está fuera del control del planificador de tiempo real y por
tanto no eliminan la impredecibilidad en el manejo de las interrupciones. La perturbación
de las ISRs se vuelve significativa cuando la frecuencia de las interrupciones es alta, ya que
esta frecuencia de interrupción tampoco es controlada por el planificador sino que depende
de los eventos externos.
HIH
IST
Objetos
Sincronización
CPU
Planificador
Prioridad Media
Peticiones de
Interrupción no
Predecibles -IRQs
Dispositivo
de E/S
Hardware de
Interrupción
(PIC)
Alta Prioridad
No expropiable y
No interrumpible
No expropiable
e interrumpible
Algoritmo de
Planificación en
Tiempo Real
Baja
Prioridad
Planificador
del Núcleo
Expropiable e
Interrupible
Eventos Predecibles Eventos No controlados (impredecibles)
Planificador/caracteristicas
"Barrera a la impredecibilidad"
Manejo a Nivel de Hilos
Ejecución
Diferida
Estado
Tarea
Variaciones
Interrupciones como
IPC: Un manejador de
bajo nivel en el núcleo
transforma las peticiones
de interrupción en IPC.
Típico de la arquitectura
de micro-núcleo.
Interrupciones como
hilos: El tratamiento a las
interrupciones se hace en
hilos del núcleo.
Interrupciones como
seudo-hilos: Las
interrupciones se manejan
en el contexto de hilos de
núcleo, pero para agilizar
la conmutación se posterga
la conversión a hilo en el
punto en que el manejador
se bloquea
Figura 14. Arquitectura de Manejo de Interrupción a nivel de Hilo
3.4.4 Eliminación de las Interrupciones
Con el propósito de evitar las dificultades del modelo tradicional para aplicaciones en
tiempo real (sección 2.6), se han propuesto varias alternativas. La más radical de ellas es
evitar completamente el empleo de las interrupciones [41]. De hecho, Stewart cataloga el
empleo indiscriminado de interrupciones como uno de los errores más comunes entre los
programadores cuando desarrollan aplicaciones de tiempo real [91]. En su trabajo se
recomienda que las ISRs de dispositivos que interrumpen periódicamente se conviertan en
tareas periódicas debido a que se pueden planificar con algoritmos de planificación de
tiempo real [60]. Siguiendo este enfoque se destaca la arquitectura disparada por tiempo
Luis Eduardo Leyva del Foyo 58
(“time-triggered architecture”) propuesta por Hermann Kopetz [46] la cual aboga por
evitar las interrupciones a favor del enfoque basado en encuesta (“polling-based”) para
interactuar con los dispositivos. Varios sistemas operativos de tiempo real han optado por
inhabilitar todas las interrupciones externas, excepto aquellas que provienen del
temporizador (necesarias para las aplicaciones básicas del sistema). En este caso, todos los
dispositivos periféricos se manejan ya sea por tareas de la aplicación, las cuales poseen
acceso directo a los registros de las tarjetas de interfaz como sucede en el núcleo RK [51]
en donde un proceso puede solicitarle al núcleo que convierta las interrupciones de
dispositivo en eventos de tiempo; o por rutinas dedicadas dentro del núcleo, activadas
periódicamente por la interrupción del temporizador y que se encargan de encuestar de
forma periódica a los dispositivos como ocurre en el sistema MARS [25]. Cualquiera que
sea el caso, debido a que no se generan interrupciones, las transferencias de datos tienen
lugar mediante encuesta.
Aunque esta solución evita completamente el no-determinismo asociado a las
interrupciones, tiene como desventaja fundamental una baja eficiencia en el uso de la CPU
en operaciones de E/S, ya sea debido a la espera ocupada de las tareas mientras acceden a
los registros del dispositivo así como al empleo de tareas de encuesta periódicas (y el
compromiso entre velocidad de respuesta y sobrecarga a la hora de elegir el período
adecuado de la encuesta).
3.4.5 Incorporación del costo de las interrupciones al análisis de Factibilidad.
Otra dirección menos radical consiste en utilizar las interrupciones pero modelar su efecto
de forma que se pueda tener en cuenta su perturbación en las ecuaciones de factibilidad de
planificación. En esta dirección se destaca el trabajo pionero de Jeffay y Stone [39] donde,
utilizando el enfoque de demanda del procesador (“processor demand”) descrito
inicialmente en [10], los autores proponen una ecuación de recurrencia para obtener la cota
superior del costo del manejo de interrupciones en ISRs durante cualquier intervalo de
tiempo dado y suponiendo que se conocen los tiempos mínimos entre llegadas de las
peticiones de interrupción (y los tiempos de cómputo de las ISRs asociadas) Su análisis es
válido para esquemas de planificación tanto con prioridades estáticas como prioridades
dinámicas. Más recientemente, varios trabajos han propuesto otros métodos de análisis que
tienen en cuenta las interrupciones como las actividades de mayor prioridad en el sistema.
Sandström, Eriksson y Fohler han propuesto un método de análisis de factibilidad de
planificación que integra las técnicas de planificación estática, con técnicas de cálculo de
tiempo de respuesta y reportan su aplicación industrial de forma satisfactoria [80].
Posteriormente, Mäki-Turja, Fohler y Sandström presentaron una modificación del análisis
exacto de tiempo de respuesta que utiliza información acerca de los instantes de liberación
y los plazos para obtener tiempos de respuesta más ajustados [39].
El trabajo de Brylow, Damgaard y Palsberg [17] presenta técnicas de análisis estático para
el análisis de software dirigido por interrupciones al nivel del código ensamblador. Estas
técnicas permiten obtener entre otros aspectos cotas máximas en la latencia de interrupción.
Stewart y Arora ampliaron la ecuación exacta de factibilidad de planificación de Lehoczky
[52] para incluir la sobrecarga de las interrupciones en sistemas de prioridades estáticas.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 59
Además se extiende el modelo de planificación presentado en [87] para tener en cuenta la
sobrecarga del tratamiento de las interrupciones. La ecuación obtenida permite evaluar los
compromisos entre realizar todo el tratamiento de la interrupción dentro de una ISR o
posponer el grueso de su tratamiento a un servidor esporádico.
La convención actual para el uso de interrupciones en sistemas de tiempo real es programar
las ISRs de modo tal que su única función sea enviar una señal a un servidor aperiódico
[87]. Entonces se utilizan los métodos de análisis en tiempo real que tengan en cuenta la
sobrecarga del manejo de interrupciones aquí presentados (por ejemplo [33] y[18])
Aunque los trabajos anteriores permiten cuantificar la interferencia de las interrupciones y
tenerlo en cuenta a la hora de aplicar los análisis de factibilidad por si mismos no consiguen
reducir (y menos evitar) la inversión de prioridad debido a las interrupciones. En la práctica
los peores casos de esta inversión de prioridad arrojan resultados excesivamente pesimistas
que demanda niveles de utilización media de la CPU excesivamente bajos aumentando
considerablemente los costos del sistema para poder garantizar las respuestas a tiempo en
los peores casos.
3.4.6 Manejo de Sobrecarga de Interrupciones
Aunque los trabajos anteriores permiten cuantificar la interferencia de las interrupciones en
la práctica su empleo se ve muchas veces limitados por la imposibilidad de conocer con
certidumbre el comportamiento temporal de las interrupciones (fundamentalmente ante
situaciones no previstas del entorno). En esta situación los sistemas dirigidos por
interrupción son vulnerables a la sobrecarga de interrupciones (“interrupt overload”): la
condición en que las interrupciones externas son señaladas con la suficiente frecuencia
como para que las demás actividades que se ejecutan en el procesador queden en inanición.
En un trabajo reciente Regehr [74] propone el empleo de un planificador de interrupciones
que no es más que una pequeña pieza de hardware o software que limita la tasa de llegada
de una fuente de interrupción. La implementación de software trabaja conmutando entre el
comportamiento por interrupción cuando la tasa de llegada es baja y comportamiento tipo
encuesta cuando la tasa de llegada es alta. Una técnica similar también fue implementada
recientemente por Coutinho, Rufino y Almeida en RTEMS utilizando filtros digitales para
modelar la tasa de llegada de las interrupciones y controlar la conmutación entre el
tratamiento por interrupciones y por encuesta [23].
3.5 Resumen
En este capítulo hemos visto las diferentes estrategias utilizadas por los sistemas operativos
para la administración de las interrupciones. Se ha puesto de manifiesto como los
mecanismos que se han ido introduciendo han tenido como propósito fundamental
aumentar el caudal de procesamiento y disminuir las latencias de interrupción y de
planificación. En otras palabras, todas estas estrategias han logrado un mejor
comportamiento en el caso promedio y una mayor rapidez de respuesta. Sin embargo, como
se destacó en la sección 2.1, tiempo real no es sinónimo de rápido sino de predecible y
desafortunadamente estas técnicas no han contribuido mucho a la predecibilidad del
Luis Eduardo Leyva del Foyo 60
sistema (operativo) en general ni tampoco resuelven todos las dificultades analizadas en el
capítulo precedente (sección 2.6). En la comunidad de tiempo real podemos identificar dos
enfoques fundamentales, el primero consiste en eliminar completamente el empleo de
interrupciones y el segundo en la ampliación de los modelos de factibilidad de planificación
para tener en cuenta el costo de las interrupciones (que se administran básicamente por los
mismos mecanismos diseñados para sistemas operativos de propósito general). El primer
enfoque es completamente radical y tiene fuertes implicaciones negativas en el uso
eficiente de los recursos del sistema (incluyendo el consumo de energía); mientras que el
segundo, tiene que ser complementado con técnicas de manejo de sobrecargas para poder
lograr predecibilidad (sección 3.4.6) y aún así trae consigo un uso ineficiente de los
recursos ahora debido a que las garantías de factibilidad de planificación sólo pueden
alcanzarse con niveles extremadamente bajos de utilización de los recursos.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 61
4Mecanismo Integrado de
Interrupciones y Tareas
En este capítulo presentamos nuestra propuesta de un modelo integrado de administración
de interrupciones y tareas. La idea de este esquema parte de la observación de que, aunque
la administración de la ISRs y las tareas se diferencia en todos los detalles, a un nivel más
conceptual esas son actividades asíncronas completamente idénticas. Como consecuencia,
un modelo que haga desaparecer todas las diferencias entre estas podrá resolver los
problemas previamente identificados en la sección 2.6 a la vez que, en virtud de su
simplicidad será más adecuada para el desarrollo de sistemas más confiables y seguros.
En este capítulo presentamos este modelo completamente integrado; así como, las
ecuaciones para los análisis de factibilidad de planificación del modelo tradicional y del
modelo integrado. Estas ecuaciones ponen de manifiesto las ventajas del modelo integrado
desde el punto de vista de predecibilidad temporal y utilización de los recursos en sistemas
de tiempo real. Posteriormente, presentamos el diseño de un subsistema de interrupciones
que puede ser utilizado para incorporar este esquema integrado en un núcleo de tiempo real.
Por último, hacemos un análisis comparativo de las características del modelo integrado
con respecto a las alternativas existentes para el manejo de eventos externos en sistemas de
tiempo real. Este análisis pone de manifiesto las ventajas de este modelo para este tipo de
sistemas.
4.1 Modelo Integrado de Tratamiento de Interrupciones y Tareas
El modelo integrado de interrupciones y tareas consiste en la unificación de dos aspectos
importantes de la administración de las interrupciones y las tareas: El mecanismo de
sincronización y el mecanismo de planificación. Como resultado de ello se logra la
existencia de un único tipo de actividad asíncrona al que denominamos tarea. La diferencia
entre las tareas convencionales (periódicas, esporádicas) y las tareas que dan servicio a las
interrupciones estriba únicamente en la naturaleza de su activación. Las primeras son
activadas por eventos de software (vencimiento de un temporizador, señal de
sincronización emitida por otra tarea, etc.) por lo que les denominamos Tareas Activadas
por Software o SAT (“software activated tasks”); mientras que las segundas son activadas
por interrupciones de hardware o IRQ, por lo que las denominamos Tareas Activadas por
Hardware o HAT (“hardware activated task”).
En este modelo integrado las HAT son las tareas que dan servicio a las interrupciones de
hardware y en consecuencia sustituyen a las ISRs. Usamos el término HAT en lugar de, por
ejemplo, Tarea de Servicio de Interrupción o IST (“Interrupt Service Task”) para
destacar la novedad del concepto y diferenciarlo de otros sistemas operativos (como los
Luis Eduardo Leyva del Foyo 62
descritos en las secciones 3.3 y 3.4.3.3) que sin llevar a cabo una integración total, también
dan servicio a las interrupciones a nivel (o en el contexto) de tareas y que pueden estar
utilizando el término IST.
A continuación detallamos el significado de este modelo integrado en términos de sus dos
componentes y valoramos sus consecuencias y el modo en el cual se resuelven los
problemas previamente planteados en la sección 2.6.
4.1.1 Integración del Mecanismo de Sincronización
La integración del mecanismo de sincronización se logra manejando todas las
interrupciones en un Manejador de Interrupciones de Bajo Nivel o LLIH (“Low Level
Interrupt Handler”) universal situado al nivel más bajo del núcleo. Este LLIH convierte las
IRQ en eventos de sincronización utilizando las mismas abstracciones u objetos de
comunicación y sincronización entre tareas que soporte el modelo de concurrencia del
sistema operativo (por ejemplo, semáforos buzones, etc).
Con este modelo, lo que antes eran ISRs ahora son HAT que permanecen en algún estado
no elegible para ejecución hasta tanto ocurra la interrupción. El estado específico en que
permanecen las HAT hasta tanto ocurra la interrupción depende del modelo de tareas. Por
ejemplo, para modelos de tareas que se ejecutan permanentemente, las HATs pudieran
bloquearse ejecutando un wait() sobre un semáforo o una variable de condición asociada a
la interrupción, (para esquemas basados en comunicación mediante memoria compartida), o
utilizando un receive() en espera de un mensaje (para esquemas que utilizan paso de
mensajes). Cuando sucede la interrupción, el LLIH universal, al nivel más bajo del núcleo,
hará lo necesario para hacer ejecutable la HAT (un signal() sobre el semáforo o variable de
condición o un send() al buzón según sea el caso). Cualquiera sea el caso, el efecto será que
se ponga lista una tarea que antes no lo estaba.
Esta variante suministra una abstracción que delega al núcleo los detalles del tratamiento de
bajo nivel de la interrupción, a la vez que elimina las diferencias entre las ISRs y las tareas.
El servicio real de la interrupción descansa aún dentro de la HAT, suministrando total
flexibilidad y haciendo innecesario que el núcleo se ocupe de las particularidades
específicas del tratamiento de las distintas interrupciones.
La existencia de un tipo único de actividad asíncrona y mecanismos uniformes de
sincronización y comunicación entre ellas ofrece, entre otras, las siguientes ventajas:
o Las HATs se ejecutan en un ambiente en donde pueden invocar sin restricción cualquier
servicio del núcleo o de alguna biblioteca.
o Facilita el desarrollo y mantenimiento del sistema, por contar con un mecanismo único
de sincronización y comunicación entre actividades cooperantes.
o Elimina completamente la necesidad de que las tareas de aplicación inhabiliten y
habiliten las interrupciones lo cual le permite al núcleo garantizar el peor caso en el
tiempo de respuesta a los eventos externos (sección 2.6.4).
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 63
o Al eliminar la necesidad de utilizar el nivel de interrupción como medio de
sincronización, no es necesario que los componentes de software conozcan el nivel de
interrupción más alto que lo invoca. Facilitando el desarrollo independiente de
componentes y bibliotecas de software sin necesidad de, ante la imposibilidad de
determinar exactamente dicho nivel, inhabilitar completamente las interrupciones.
o Se elimina la dificultad asociada al levantamiento de excepciones como parte de los
manejadores de interrupción (sección 2.6.2) ya que estos se ejecutan en su propio
contexto de tarea.
Observe que esta integración es más completa de la que se logra con la implementación de
interrupciones como hilos en Solaris o Linux (sección 3.3) ya que en estos sistemas lo que
sucede en realidad es que las ISRs se ejecutan en el contexto de hilos dedicados; sin
embargo, la activación de las mismas no se hace utilizando los mecanismos de
sincronización estándares. En otras palabras el tratamiento de interrupciones se sigue
realizando mediante un conjunto de servicios específicos que permiten la instalación de
ISRs. Solo que las ISRs ahora se ejecutan en su propio contexto de hilo y no en el contexto
del hilo interrumpido.
4.1.2 Integración del Mecanismo de Planificación
La unificación del mecanismo de sincronización es sólo un paso necesario pero no
suficiente. El mecanismo integrado incluye un espacio de prioridades dinámicas unificado y
flexible para todas las actividades (sean activadas por eventos de software o de hardware).
El planificador del núcleo y el hardware de interrupciones cooperan para planificar todas
las actividades asíncronas sean SAT o HAT utilizando un espacio unificado de prioridades
bajo un mismo algoritmo de planificación (ver Figura 15).
Planificador
del Núcleo.
Hardware de
Interrupciones
Espacio de
Prioridades
Unificado
( Manejadores de
Interrupción )
( Tareas )
Máxima
Mínima
Figura 15. Prioridades en el esquema integrado
Es importante destacar que esta planificación integrada incluye la planificación de las IRQs
(no sólo la HAT asociada). Esta es una diferencia fundamental con otras propuestas (como
las descritas en las secciones 3.3 y 3.4.3.3) que integran la planificación de las actividades
(hilos) de interrupción y en las que todavía las mismas IRQs quedan completamente fuera
del control del planificador y por tanto pueden llegar en cualquier momento. La necesidad
Luis Eduardo Leyva del Foyo 64
de planificar las IRQ como tal es la razón por la cual es necesaria la participación del
hardware de interrupciones en la planificación.
Este esquema de planificación unificado permite que a todas las actividades del sistema de
tiempo real se le asignen prioridades en correspondencia con sus restricciones de tiempo.
Con ello, se obtienen las siguientes ventajas:
o Se evita la implementación de un protocolo de entrada/salida (EnterISR-LeaveISR)
para registrar las ISRs en el núcleo evitando los errores potenciales (sección 2.6.1.2).
o Se evita la inversión de prioridad asociada al espacio de prioridades independiente
(sección 2.6.3).
o Se elimina el error del cierre de interrupción roto, producto de la conmutación de tareas
(sección 2.6.1.1).
o Las situaciones de sobrecargas de interrupciones se pueden manejar utilizando
cualquiera de las técnicas de planificación conocidas para el manejo de sobrecarga;
como por ejemplo, el empleo de un servidor esporádico (ver [87]).
IST Tarea
HIH Estado
En el
modelo
integrado
se planifican
las
IRQs
Modelo Integrado
CPU
Peticiones de
Interrupción no
Predecibles -IRQs
Dispositivo
de E/S
Algoritmo de
Planificación en
Tiempo Real
Baja
Prioridad
Planificador
del Núcleo
Expropiable e
Interrupible
Eventos Predecibles Eventos No controlados (impredecibles)
Planificador/caracteristicas
"Barrera a la impredecibilidad"
Ejecución
Diferida
Objetos
Sincronización
Variaciones
Implementación en
hardware mediante FPGAs
Algoritmos de emulación
en software (Ver siguiente
capítulo)
Figura 16. Arquitectura del Manejo de Interrupción del Modelo Integrado
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 65
4.1.3 Arquitectura de Interrupciones del Modelo Integrado
La Figura 16 muestra un esquema de la arquitectura del manejo de interrupciones del
modelo integrado aquí propuesto y que puede ser contrastada con las figuras
correspondientes a los esquemas tradicionales presentadas en la sección 3.4. Como puede
apreciarse, la diferencia fundamental de nuestro esquema con respecto a los esquemas
anteriores es que ahora las mismas IRQ están bajo el control del planificador de tiempo real
del sistema. Por consiguiente, ahora el Manejador de Interrupciones de Hardware ejecuta el
LLIH bajo el control del planificador de tiempo real convirtiéndose en una entidad
planificable. Como consecuencia, nuestro esquema integrado ha eliminado completamente
las entidades no planificables presentes en las arquitecturas tradicionales de manejo de
interrupciones dando como resultado un esquema de manejo de interrupciones
completamente predecible.
4.2 Análisis de la Factibilidad de Planificación en Ambos Modelos Incorporando las
Interrupciones
Con el propósito de valorar la factibilidad del modelo integrado desde el punto de vista de
la planificación en tiempo real, a continuación hacemos un análisis de la disminución en la
cota de planificación y el aumento del tiempo de respuesta producto de la utilización de
espacios de prioridades independientes en el modelo tradicional. Posteriormente analizamos
la disminución de la cota de planificación introducida por la conmutación de contexto del
modelo integrado. Estos resultados permitirán valorar bajo que condiciones es más
apropiado un modelo u otro.
4.2.1 Disminución de la Cota de Utilización de Tasa Monótona
Según la teoría del Análisis de Tasa Monótona o RMA, una tarea ti es factible de planificar
utilizando la asignación de prioridades monótona en plazo si se cumple que:
U Ui lub (1)
dónde Ui es la menor cota superior de utilización (“least upper utilization bound”) de la
CPU, que para una asignación de prioridades estáticas como la Planificación de Tasa
monótona (“Rate Monotonic Scheduling”) es i(21/i-1), o 1 si se utiliza una asignación de
prioridades dinámico como Primero el Plazo más Próximo (“Earliest Deadline First”). Se
supone que la Ui es la fracción de utilización de la CPU debido a la tarea ti, más la fracción
de utilización de la CPU producto de la interferencias de las tareas de mayor prioridad.
Esto se puede expresar como:
j P(i ) j
j
i
i
i T
C
T
C
U (2)
donde Ci es el tiempo de cómputo de la tarea ti y Ti es su período. P(i) es el conjunto de
tareas tj de mayor prioridad que ti con período Tj < Ti y tiempos de cómputo Cj.
Luis Eduardo Leyva del Foyo 66
Ck
L
Ck
S
tk
S S(i)
ti
tk
LL(i)
Tk
S < Ti < Tk
L
Tk
S
Tk
L
Ti Ci
ISRs
Tasks
Mayor
Prioridad
Menor
Prioridad tiempo
( no de
tiempo real )
perturbación
(tiempo real)
(tiempo real)
Figura 17. Perturbaciones Temporales debido al espacio prioridades de tareas e
interrupciones independiente.
La perturbación temporal (“timing disturbance”) que ejercen las ISRs sobre la
planificación de una tarea ti de tiempo real crítico se puede describir utilizando la Teoría de
Planificación en Tiempo Real Generalizada [44]. Como se muestra en la Figura 17, en este
caso tenemos dos tipos de perturbaciones:
Aquella asociada a interrupciones con tiempos mínimos entre llegadas inferiores a los
de la tarea de tiempo real i t pero que no están asociadas a tareas sin requerimientos de
tiempo real (o con requerimientos de tiempo real suave). A esta perturbación le
llamaremos perturbación debido a tareas no críticas. Denotemos por S(i) al conjunto
de ISRs tk
S con estas características, cada una con tiempos de cómputo Ck
S y períodos
Tk
S < Ti. La utilización de una ISR tk
S en el conjunto S(i) está dada por Ck
S/Tk
S.
Aquella asociada a ISRs con requerimientos de tiempo real crítico, pero que poseen un
tiempo mínimo entre llegadas mayor que el de la tarea ti. A esta perturbación se llama
inversión de prioridad monótona en tasa. Denotemos por L(i) el conjunto de ISRs tk
L
con estas características y por Ck
L el tiempo de cómputo de cada una de ellas. Como los
tiempos entre llegadas Tk
L de estas interrupciones son mayores que Ti, sólo pueden
expropiar a ti una sola vez. En consecuencia, la utilización en el peor caso debido a una
ISR en el conjunto L(i) está dada por Ck
L/Ti.
La ecuación de la cota de utilización teniendo en cuenta estas dos afectaciones quedaría
entonces como:
( ) ( ) ( )
1
k L i
L
k
k S i i
S
k
S
k
j P i j
j
i
i
i C
T T
C
T
C
T
C
U (3)
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 67
Los dos primeros términos son idénticos a los de la ecuación (2). Por tanto, el tercer y el
cuarto término se pueden interpretar como la disminución que se produce en la menor cota
superior de utilización (Ulub) debido a la utilización de un espacio independiente de
prioridades de interrupción. Sea esta disminución Uis, entonces la ecuación (1) se puede
escribir:
net is U U U lub (4)
donde:
( ) ( )
1
k L i
L
k
k S i i
S
k
S
k
is C
T T
U C (5)
Obsérvese sin embargo que la ecuación (3) no tiene en cuenta la afectación a la utilización
debido a la necesidad de inhabilitar las interrupciones. Sea IL el tiempo máximo durante el
cual se inhabilitan las interrupciones en cualquier parte del sistema, entonces la ecuación
(3) se puede extender fácilmente como:
L
k L i
L
k
k S i i
S
k
S
k
j P i j
j
i
i
i C I
T T
C
T
C
T
C
U
( ) ( ) ( )
1
Por tanto, la disminución de la cota de planificación teniendo en cuenta la inhabilitación de
interrupciones *
is U quedaría como:
L
k L i
L
k
k S i i
S
k
S
k
is C I
T T
U C
( ) ( )
* 1 (6)
4.2.1.1 Solución tradicional
Con el propósito de minimizar Uis, el código de las ISRs (Ck
S, Ck
L) debe ser mínimo. De
esta forma, una ISR sólo hará el procesamiento necesario para evitar la pérdida de datos y
activar una tarea que llevará a cabo el servicio adicional que necesite la interrupción.
Precisamente este es el fundamento para el esquema manejo de interrupciones a nivel de
hilos previamente descrito en la sección 3.4.3.3 (y la Figura 14) del capítulo anterior en el
cual el manejo de la interrupción se divide en una pequeña ISR o HIH y una Tarea de
Servicio de Interrupción o IST. Con este esquema, la respuesta real a un evento ocurre
entonces dentro de esta tarea con la cuál la ISR se comunica. Una vez activada, esta tarea se
ejecutará, igual que cualquier otra, bajo el control del planificador del núcleo y se le puede
asignar una prioridad según los requerimientos de la aplicación.
La Figura 18 muestra el comportamiento temporal del mismo conjunto de tareas mostrado
en la Figura 17 pero ahora utilizando este esquema de manejo de interrupciones a nivel de
hilos. Como se puede observar, ahora cada una de las ISRs (actividades en los conjuntos
S(i) y L(i)) hacen un procesamiento mínimo y provocan la activación de las
correspondientes ISTs. Como puede observarse en la Figura 17, estas ISTs pertenecen al
Luis Eduardo Leyva del Foyo 68
conjunto U(i) de tareas que poseen menor prioridad que la tarea de ti y por tanto no
interfieren con la ejecución de la tarea ti
ISRs
Mayor
Prioridad
Menor
Prioridad
perturbación
Tk
S Ck
Tk S
S < Ti < Tk
L
Ti Ci
Tk
L Ck
L
tk
S S(i)
( no de
tiempo real)
ti
LL(i)
( tiempo real)
ti
(tiempo real)
Tareas
tk
U U(i)
(no interfieren)
Figura 18. Perturbación temporal utilizando el esquema de manejo de interrupciones en
dos niveles (ISR y tareas).
En realidad, aunque esta estrategia consigue minimizar la perturbación producida por las
ISRs, no resuelve el problema de la predecibilidad. Este problema se origina por la
incapacidad de predecir la frecuencia de las interrupciones provenientes de todos los
dispositivos en el sistema (Tk
S). La ocurrencia de demasiadas interrupciones en un pequeño
intervalo de tiempo hace al sistema no predecible y puede provocar que algunas tareas
incumplan sus plazos. Con el propósito de abordar este problema algunos sistemas
introducen mecanismos adicionales para limitar el número de interrupciones durante ciertos
intervalos de tiempo [68], [74]. Sin embargo, está claro que estos mecanismos introducen
una sobrecarga operativa adicional.
4.2.2 Incremento en el tiempo de respuesta de las tareas (a eventos externos)
Con el esquema anterior, el tiempo de respuesta de extremo a extremo real del evento
coincide con el tiempo de respuesta en el peor caso de la tarea asociada con la cual la ISR
se comunica. En [18] se ofrecen ecuaciones para obtener el tiempo de respuesta real a un
evento externo utilizando varias estrategias para modelar las ISRs. Sin embargo, nosotros
estamos interesados en obtener la afectación que ejerce la existencia de dos espacios de
prioridades independientes sobre el tiempo de respuesta.
Como es de suponer la existencia de espacios de prioridades independientes se debe reflejar
en un aumento en el tiempo de respuesta de las tareas. El tiempo de respuesta Ri de una
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 69
tarea ti con tiempo de cómputo Ci y tiempo mínimo entre llegadas Ti se puede obtener
mediante la siguiente ecuación de recurrencia [7]:
j
j P i j
n
i
i i
n
i C
T
R
R C B
( )
1
(7)
Donde Ri
0 representa el valor inicial de Ri (puede tomarse como Ci) y Ri
n es el n-ésimo
valor iterativo. Bi es el tiempo de bloqueo que experimenta la tarea ti y P(i) el conjunto de
tareas con mayor prioridad que ti. El tercer término de esta ecuación representa la
interferencia total que experimenta ti debido a las tareas en el conjunto P(i). Esta iteración
termina satisfactoriamente cuando se encuentra un tiempo de respuesta Ri = Ri
n-1 = Ri
n; o
no satisfactoriamente, cuando Ri
n > Di. Siendo Di el plazo de la tarea ti.
Para tener en cuenta el efecto que sobre el tiempo de respuesta de la tarea ti ejerce la
existencia de un espacio de interrupciones independientes, tenemos que añadirle a la
ecuación (7) la interferencia que los conjuntos de ISRs S(i) y L(i) ejercen sobre el tiempo de
respuesta. La ecuación quedaría como:
( ) ( )
1
( )
1
k L i
L
k
S
k
k S i k
n
i
j
j P i j
n
i
i i
n
i C C
T
R
C
T
R
R C B (8)
Para una mejor interpretación la ecuación está dividida en dos secciones delimitadas por
paréntesis. La primera sección incluye tres términos idénticos a los de la ecuación (7). El
primer término de la segunda sección introduce la afectación debida las ISRs en el conjunto
S(i) (que pueden expropiar múltiples veces a la tarea ti) mientras que el segundo término de
la segunda sección introduce la afectación debida a las ISRs en el conjunto L(i) (que en el
peor caso, sólo pueden expropiar una vez a la tarea ti). Esta segunda sección se puede
interpretar como la afectación en el tiempo de respuesta Ri debido a la utilización de un
espacio de prioridades de interrupción independiente. Sin embargo, debido a que (8) es una
ecuación de recurrencia, no podemos cuantificar ambas secciones de forma independiente
como se hizo para el caso de la utilización. Mucho más importante es la observación de que
un incremento muy pequeño en la contribución de la segunda sección de la ecuación puede
dar como resultado un incremento muy grande en el tiempo de respuesta de la tarea que
puede llevar al incumplimiento del plazo.
4.2.3 Sobrecarga por la introducción de la conmutación de contexto entre tareas.
El inconveniente de un tratamiento integrado como el propuesto aquí, está dado por la
sobrecarga introducida en la conmutación de contexto hacia tareas que antes se trataban
como ISRs. Esta sobrecarga se refleja, como es natural, en una disminución del límite
superior de la cota de planificación.
Sea H(i) el conjunto de todas las actividades tj
H con un tiempo de ejecución Cj
H y tiempo
mínimo entre llegadas Tj
H menor que el período Ti de la tarea ti y cuyo tratamiento se hace
en una ISRs en el modelo tradicional. Sea I el tiempo total de CPU consumido por el
Luis Eduardo Leyva del Foyo 70
esquema de entrada/salida a la ISR necesario para salvar y restaurar el estado de la CPU y
registrar el anidamiento de las ISRs (por ejemplo mediante el protocolo EnterISRLeaveISR
descrito en la sección 2.6.1.2). Sea cj
H el tiempo de CPU del código de atención a
la interrupción como tal. Entonces, bajo el esquema tradicional, el tiempo total de CPU de
una ISR en el conjunto H(i) se puede expresar como:
I Hj
Hj
C c
Entonces, en la ecuación (2), el segundo término puede descomponerse en dos partes: el
consumo de CPU debido a las ISRs que, en virtud de sus períodos inferiores al período de
la tarea ti, les corresponde una prioridad de tasa monótona mayor a la prioridad de la tarea ti
(conjunto H(i)) y el resto de las tareas de mayor prioridad que no son ISRs (conjunto P(i) –
H(i)). Haciendo esta descomposición, la ecuación (2) se puede escribir como:
( ( ) ( )) j H(i)
H
J
I Hj
j P i H i j
j
i
I i
i T
c
T
C
T
C
U
(9)
Por el contrario, en el modelo integrado todas las actividades en el conjunto H(i) se tratan
como tareas. Sea P el tiempo de conmutación de contexto del sistema. Entonces, el
consumo de CPU Hj
C de una tarea en el conjuntoH(i) se puede expresar como:
H P
j
H
j C c 2
Donde 2δP tiene el cuenta el tiempo de las dos conmutaciones de contextos asociadas a la
expropiación para la ejecución de una tarea en H(i) y al regreso de esta a la tarea
expropiada. En consecuencia, para el casi del modelo integrado, la ecuación (2) se puede
escribir como:
( ( ) ( )) ( )
2
j H i
H
J
H p
j
j P i H i j
j
i
P i
i T
c
T
C
T
C
U
(10)
Por tanto, la disminución en la utilización Ui
PI debido a la sobrecarga asociada al
tratamiento de las actividades en el conjunto H(i) como tareas, en lugar de hacerlo como
ISRs. Que es lo mismo que la disminución en la utilización debido al empleo de un modelo
integrado de tratamiento de interrupciones y tareas, está dado por:
( ) ( ) ( )
2 2
j H i
H
J
p I
j H i j
I Hj
j H i j
p Hj
I
i
p
i
PI
i T T
c
T
c
U U U
j H(i )
H
J
PI
i T
U (11)
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 71
donde 2p I es la diferencia entre el tiempo de cómputo de dos conmutaciones de
contexto y el tiempo de cómputo del protocolo de entrada/salida a la ISR.
La sobrecarga del modelo integrado será menor que el efecto de inversión de prioridad del
modelo tradicional si se cumple la siguiente condición:
iS
PI
i U U (12)
A partir de la ecuación (12), si se compara la disminución en la cota de planificación
debido al empleo del modelo tradicional de tratamiento de interrupciones UiS (ecuación 5) y
UiS
* (ecuación 6), con la disminución que introduce el modelo integrado Ui
PI (ecuación 9)
debido a la sobrecarga adicional en la conmutación de contexto, es posible observar que en
la mayoría de los casos el ahorro que se obtendría mediante el tratamiento al nivel de ISR
utilizando el modelo tradicional, es mucho menor que la reducción de la cota de factibilidad
de planificación que este introduce, debido a los diferentes tipos de inversión de prioridad
que trae aparejado.
En cualquier caso, pudiera ser posible diseñar un modelo híbrido con una configuración en
la cual algunas actividades son tratadas como ISRs y otras como HATs para satisfacer la
condición establecida en (12). Por ejemplo, cómo la interrupción del temporizador siempre
tendrá la mayor prioridad en el sistema y nunca será manejada por una aplicación, podría
ser considerada una ISR. Esto reduce el conjunto H(i) y por tanto disminuye Ui
PI.
4.3 Diseño del Subsistema de Administración de Interrupciones de Bajo Nivel para
un micro-núcleo experimental.
En esta sección damos una breve descripción del diseño de un subsistema de
administración de interrupciones de bajo nivel para la implementación del modelo
integrado de administración de interrupciones y tareas anteriormente descrito. Hemos
establecido como requerimiento que este subsistema suministre un nivel de abstracción tal
que permita que el resto del núcleo sea completamente independiente del hardware de
interrupciones específico de la plataforma.
El diagrama UML de la Figura 19, muestra las relaciones entre los diferentes
componentes14 del núcleo involucrados en la administración de interrupciones. Todos los
componentes del núcleo que tienen que interactuar con el componente de administración de
interrupciones lo hacen a través de la interfaz iKRNLINT. Por tanto, cualquier
implementación del subsistema de administración de interrupciones tiene que suministrar
una realización de esta interfaz.
14 Independientemente de cualquier significación que se le de al término componente en el contexto del diseño
de software basado en componentes, en este trabajo entendemos por componente una unidad de software en
formato ejecutable que brinda una abstracción bien definida y a cuyos servicios; así como a su configuración,
se pueden acceder a través de una interfaz de modo que puede ser: (1) intercambiado fácilmente por otro
componente que implemente la misma interfaz o, reutilizado en otro proyecto de software que haga uso de la
misma interfaz.
Luis Eduardo Leyva del Foyo 72
+setInterruptPriority)() : void
+getInterruptPriority() : Byte
+getIntrSyncSet() : SYNCSET
+initKrnlInt() : void
+endKrnlInt() : void
«interface»
iKRNLINT
+IRQHandler(irq:BYTE)() : void
+panic(irq:BYTE)() : void
«implementation class»
KRNLINT
+enableIrq() : int
+disableirq() : int
+setIrqPriority() : void
+setIrqLevel() : void
+endIrq() : void
+initIrqHardware() : void
+restoreIrqHardware() : void
«interface»
iINTHAL
+addSync() : int
+deleteSync() : int
+getSync() : SYNCID
SYNCSET
Interfaz del INTHAL
Abstracción de Objetos
de Sincronización ofrecida
por el módulo de comunicación
y sincronización
Figura 19. Diagrama UML que muestra los diferentes módulos del subsistema de
administración de interrupciones de bajo nivel del núcleo.
A su vez, el componente administrador de interrupciones está subdividido en otros dos
componentes. Uno denominado Módulo de Administración de Interrupciones del Núcleo
(KRNLINT) que contiene el código de administración independiente del hardware, y otro
que contiene el código dependiente del hardware y que recibe el nombre de Capa de
Abstracción del Hardware de Interrupciones (INTHAL). Toda la comunicación entre el
componente KRNLINT y el componente INTHAL se realiza a través de la interfaz
iINTHAL.
4.3.1 Módulo de Administración de Interrupciones del Núcleo
La responsabilidad fundamental del módulo de administración de interrupciones del núcleo
es el suministro de mecanismos de bajo nivel que le permitan al resto del sistema (en
específico a los módulos de planificación y de comunicación y sincronización) tratar a las
interrupciones con las mismas políticas de planificación o de sincronización de tiempo real
que aplica a las tareas. Entre sus responsabilidades se encuentran:
permitir la asociación de objetos de sincronización (abstracciones de
sincronización de alto nivel que soporte el modelo de concurrencia del núcleo –
semáforos, buzones, etc) todos ellos identificados por un identificador de
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 73
sincronización de tipo SYNCID único en el sistema, a cada una de las líneas de
petición de interrupción del hardware;
generar una señal sobre los objetos de sincronización cada vez que se produzca una
petición de interrupción por la línea asociada; así como,
suministrar los mecanismos que permitan la administración de las prioridades de las
interrupciones de forma dinámica.
Para ello este módulo crea la abstracción de Interrupción del Núcleo cada una de las
cuales se identifican por unos identificadores de interrupción de tipo IRQID
predefinidos. A cada interrupción del núcleo se le puede asociar una prioridad dentro de
un espacio unificado de prioridades para interrupciones y tareas). Como se puede observar
en la Figura 19, la interfaz iKRNLINT brinda los servicios setInterruptPriority() y
getInterruptPriority() para establecer y obtener la prioridad de una Interrupción del
Núcleo (en la implementación actual este valor puede estar entre 0 y 255). Se ofrece
tambien el servicio getIntrSyncSet() para obtener el conjunto de objetos de sincronización
asociados a cada interrupción. A través de este servicio el resto del núcleo puede
inspeccionar, añadir y eliminar objetos de sincronización asociados a una interrupción.
Adicionalmente (ver Figura 19), la interfaz iKRNLINT brinda el servicio initKrnlInt()
que debe ser invocado como parte del arranque del sistema para inicializar el componente
de administración de interrupción.
4.3.2 Capa de Abstracción del Hardware de Interrupciones
La Capa de Abstracción del Hardware de Interrupciones, INTHAL (“Interrupt
Hardware Abstraction Layer”) es la responsable del tratamiento de las interrupciones a más
bajo nivel. Esta se ocupa de los aspectos dependientes del hardware de interrupción de la
máquina de forma que el resto del sistema sea lo más independiente posible de su
arquitectura. Entre sus funciones se encuentran:
Suministrar un conjunto de líneas de petición de interrupción del sistema
independiente de la arquitectura. Estas líneas se denotan por IRQ (“Interrupt
Request”) y van desde IRQ0 hasta IRQn (donde el número n depende del sistema).
Suministrar la capacidad de establecer dinámicamente las prioridades de cada una
de las líneas IRQx, de forma arbitraria e independiente del sistema de prioridades
del hardware de interrupciones real de la máquina.
Suministrar la capacidad de establecer un nivel de interrupción por debajo del cual
las interrupciones están inhabilitadas.
La prioridad de cada una de las interrupciones puede situarse en un valor arbitrario (e
independiente de la arquitectura) que va desde 0 hasta 255, siendo 255 la mayor prioridad y
1 la menor (ver figura Figura 20). El valor 0 está reservado e indica que el nivel de
Luis Eduardo Leyva del Foyo 74
interrupción correspondiente está inhabilitado. Sin embargo, el HAL asigna a cada petición
de interrupción una prioridad de hardware por defecto cuyo orden de prioridad (no los
valores absolutos) coincide con el impuesto por el hardware de interrupción del sistema. El
HAL de interrupciones sitúa estas prioridades por defecto en el rango configurable que se
especifique mediante los valoresMaxDefault y MinDefault.
Nivel de IRQ Comentario
255
Niveles de prioridad de interrupción asignados explícitamente mediante
los servicios EnableIRQ() y SetIRQPriority()
MaxDefault
MinDefault
Rango de prioridades en que sitúan las prioridades por defecto de las
interrupciones. Aquellas habilitadas con EnableIRQ(IRQx, 0).
IRQLevel Nivel de interrupción por debajo del cual las interrupciones están
inhabilitadas. El valor IRQLevel puede situarse en cualquier posición.
0
Figura 20. Niveles de Prioridad del INTHAL
La Figura 21 muestra el diagrama de estados UML (“statechart”) de las IRQs. En lo que
concierne al núcleo, las IRQ pueden estar en dos estados: capturadas o ignoradas.
Interrupciones ignoradas: Son todas aquellas interrupciones que el núcleo no ha
solicitado atender. Si se produjera una interrupción ignorada entonces se considera
un error y se invoca al servicio panic(). Cuando se inicia el sistema, todas las IRQs
se encuentran en este estado.
Interrupciones capturadas: Son aquellas que el núcleo ha solicitado atender de
forma explícita mediante la invocación al servicio enableIrqQ().
Además, una interrupción capturada puede estar habilitadas o inhabilitadas.
Interrupciones habilitadas: son aquellas cuyo nivel IRQ está por encima del nivel
IRQ actual de la CPU (IRQLevel). La activación de las IRQ capturadas y
habilitadas provocan la invocación de la rutina IRQHandler() del núcleo.
Interrupciones inhabilitadas: son aquellas cuyo nivel IRQ es menor o igual que el
nivel IRQ actual de la CPU (IRQLevel). Las interrupciones inhabilitadas,
independientemente de que hayan sido capturadas, no provocan la invocación de
IRQHandler().
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 75
El servicio initIrqHardware() debe ser invocado como parte del arranque del núcleo del
sistema y sirve para inicializar el INTHAL. Como se dijo antes, al iniciar el sistema, todas
las IRQ están inhabilitadas. Puede utilizarse el servicio enableIrq( irq, priority ) para
habilitar la captura de la petición de interrupción especificada en el parámetro IRQ. El
parámetro priority especifica el nivel de prioridad deseado para la IRQ. Si dicho parámetro
se sitúa en 0 se utiliza el nivel de prioridad por defecto. Este servicio puede devolver
ERROR debido a que la IRQ especificada ya ha sido previamente capturada.
captured
ignored
enabled
disable
setIrqLevel(priority)
/IrqPriority = priority
enableIrq(irq,priority)
/irqPriority = priority
setIrqPriority(irq,priority)
/irqPriority = priority
irqPriority > irqLevel
irqPriority Px > Pi). Esto no sólo implicaría un nuevo enmascaramiento de
IRQs; sino que también, arroja un peor caso más grande que el necesario en la
perturbación causada por interrupciones indebidas.
3. Enmascarar todas las IRQs con prioridades menores o iguales que Pc: esta opción
equivale a igualar el nivel de IRQ físico (máscara física) con el nivel de prioridad del
sistema (nivel de IRQ virtual). Con esto se garantiza que una vez ocurrida la
interrupción indebida, no ocurrirá ninguna otra interrupción indebida mientras el nivel
de prioridad del sistema sea mayor o igual al nivel actual. En esta variante, el servicio
serIrqLevel() tiene que calcular la máscara de interrupción correspondiente a cada
nivel que se establezca, independientemente de si se invoca para elevar o para disminuir
el nivel de prioridad actual del sistema. Esto tiene como inconveniente una mayor
sobrecarga en la conmutación de contexto pero ofrece la ventaja de que para cada nivel
de prioridad puede ocurrir sólo una interrupción indebida (su ocurrencia enmascara
todas las demás) lo que arroja el mejor valor posible de la la perturbación en el peor
caso debido a interrupciones indebidas.
5.5.3.2 Mecanismo para “recordar” la IRQ indebida
Una vez ocurrida y enmascarada una interrupción indebida, esta debe recordarse para
cuando la prioridad del sistema baje lo suficiente como para permitir su ocurrencia. En este
aspecto, la propia existencia del modelo integrado de administración de interrupciones
(planificación y sincronización) posibilita dos opciones fundamentales en dependencia de
qué componente tiene la responsabilidad de memorizarlas:
1) La responsabilidad de “memorizar” se sitúa en el propio VCPIC (INTHAL). Esta
es la opción equivalente a la idea original del prologo de interrupción en el
enmascaramiento optimista. Para lograr esto habría que mantener un indicador de
ocurrencia para cada posible IRQ (“continuación” en la terminología de Stodolsky
[93]), donde se recordarían las interrupciones indebidas ocurridas. Luego, al bajar el
nivel de prioridad, se simularía su ocurrencia invocando a IRQHandler(IRQ) dentro
del servicio del HAL setIrqLevel(). Esta opción tiene como ventaja la total
transparencia del núcleo con respecto al modo de enmascaramiento que utilice el
INTHAL.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 101
Vale la pena señalar que esta opción es la única disponible cuando se utiliza un
esquema convencional de manejo de interrupciones. Obsérvese además que ello
implicar un incremento en el tiempo de cómputo del servicio setIrqLevel(). En el caso
del esquema convencional de administración de interrupciones y tareas, y para los
sistemas operativos de propósito general para los cuales el enmascaramiento optimista
fue diseñado, esto no constituye una dificultad, ya que la invocación a setIrqLevel() no
se realizar como parte de cada conmutación de contexto, sino como parte del protocolo
de entrada/salida a las secciones críticas del núcleo y siempre este servicio será más
económico que la alternativa de manipular directamente el nivel de interrupción (que es
precisamente la razón por la cual se introdujo el enmascaramiento optimista).
Para el caso del esquema integrado de administración de interrupciones y tareas, y para
los sistemas operativos de tiempo real, lo anterior no es válido. Ello se debe primero a
un rediseño completo del paradigma de implementación y por otro a los objetivos de
diseño:
o Ahora setIrqLevel() no se invoca como parte del protocolo de entrada/salida a las
secciones críticas del núcleo sino que se invoca como parte de cada conmutación de
contexto. De hecho, la propia conmutación de contexto constituye una sección
crítica del kernel por tanto no es posible simular una interrupción desde
setIrqLevel(). Obsérvese que con el empleo del modelo integrado aquí propuesto se
elimina completamente la necesidad de inhabilitar las interrupciones dentro del
micro-núcleo. Las secciones críticas más internas del mismo se protegen
simplemente inhabilitando la expropiación (protocolo de techo de prioridad
inmediata), mientras que las secciones críticas más externas se protegen utilizando
mutexes (que pueden implementar cualquiera de los protocolos de herencia de
prioridades disponibles).
o La eficiencia del esquema integrado, y el grado de factibilidad de planificación que
puede alcanzar el sistema como tal, es muy sensible al tiempo de ejecución en el
peor caso del servicio setIrqLevel(). Por consiguiente cualquier mínimo incremento
en el mismo constituye un inconveniente significativo.
2) La responsabilidad de “memorizar” se sitúa en el núcleo (KRNLINT).
Afortunadamente la solución a estas aparentes dificultades a la hora de utilizar este
esquema de enmascaramiento optimista para el caso del modelo integrado se
encuentran en su mismo diseño, el cuál no sólo integra el esquema de prioridades sino
que también ofrece un mecanismo integrado de comunicación y sincronización entre
manejadores de interrupción y tareas. Bajo este modelo no se hace necesario que el
VCPIC le oculte al núcleo la ocurrencia de una interrupción indebida. Ahora se abre la
posibilidad de notificarle este evento al núcleo para que este sea el que se encargue de
recordarla. Existen dos alternativas en que el VCPIC le puede notificar al núcleo la
ocurrencia de una interrupción indebida: (1) invocar a un punto de entrada
(IRQHandler (IRQ)) siempre que ocurriese una interrupción debida y a otro punto de
entrada distinto en los casos en que la interrupción sea indebida; (2) invocar siempre a
un mismo punto de entrada pero con un parámetro adicional que indica si la
interrupción es debida o indebida (IRQHandler(IRQ, flag)). Sin embargo, obsérvese
Luis Eduardo Leyva del Foyo 102
que realmente no se hace necesario que el VCPIC le indique al núcleo si la interrupción
que se produjo es debida o indebida ya que este tiene suficiente información para
diferenciar la una de otra (con el nivel de prioridad del sistema) e incluso pudiera
hacerlo de forma totalmente transparente.
El hecho está en que cuando ocurre una interrupción (se invoca a IRQHandler(irq)) la
tarea del núcleo es señalar a los objetos de sincronización asociados a dicha IRQ e
invocar al planificador. Si se establece la restricción (ya conveniente de todas formas)
de que sólo pueden asociarse a una IRQ objetos que tengan capacidad de memorizar las
señales (semáforos, buzones) entonces se garantiza de forma totalmente transparente la
capacidad de recordar una interrupción indebida. En este caso, una interrupción debida
provocaría la expropiación de la tarea actualmente en ejecución en favor de la IST que
espera por ella (esta tiene mayor prioridad) mientras que la ocurrencia de una
interrupción indebida pondría en listo a la IST correspondiente pero no provocaría
expropiación de la tarea actualmente en ejecución (su IST posee menor prioridad). Esta
sería planificada automáticamente cuando el nivel de prioridad del sistema baje lo
suficiente.
En el caso de que se esté en modo de enmascaramiento virtual y ocurre una interrupción i
cuya prioridad Pi > Pc, entonces el LLIH del INTHAL debe realizar las mismas
operaciones que en el modo de enmascaramiento físico con la excepción del
enmascaramiento de la IRQ.
La tabla de la Figura 34 resume las diferencias entre la idea inicial del enmascaramiento de
interrupciones optimistas (propuesta en [93]) y la adaptación que hemos realizado para
adecuarla a sistemas de tiempo real con el modelo integrado de administración de
interrupciones y tareas. A esta adaptación le denominamos enmascaramiento virtual.
Técnica Enmascaramiento Optimista Enmascaramiento Virtual
Sistemas a los
que se destina
Sistemas operativos de
Propósito general
Sistemas operativos de
tiempo real
Enmascaramiento
Físico
Opcional, con el propósito de
simplificar la implementación
Obligatorio, con el propósito de
garantizar la predecibilidad
temporal
Omisión de la
ejecución del
manejador de
IRQ indebida
Explícita por parte del prólogo de
cada ISR
Automático por parte del
planificador del núcleo (la tarea
no se ejecuta porque no tiene
suficiente prioridad)
Registro de
Interrupcio-nes
Indebidas
Explícito como parte del prólogo de
cada ISR
Automático como parte del
objeto de sincronización saciado a
la IRQ
Ejecución del
manejador
pospuesto
Explícito como parte del protocolo
de salida de las secciones críticas.
Automático por parte del
planificador del núcleo (cuando
sea la tarea de más prioridad)
Figura 34. Diferencias entre enmascaramiento optimista y virtual
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 103
5.5.4 Soporte de Interrupciones sensibles al Nivel
Cualquiera de los esquemas de enmascaramiento virtual descritos en la sección 5.5.3
funciona sin ningún tipo de dificultad para el caso de que las líneas de petición de
interrupción sean sensibles al flanco (ver sección 5.1.1) ya que en este caso aunque LLIH
no elimine la causas que originó la petición de interrupción (ni enmascare la interrupción en
el IMR del PIC) no se generarán más peticiones de interrupción. Sin embargo, como se
planteo anteriormente, el problema con las líneas de petición de interrupción sensibles al
flanco es que no pueden ser compartidas de forma confiable entre múltiples dispositivos
periféricos. En los sistemas con bus EISA o PCI es posible programar la sensibilidad (al
nivel o al flanco) de cada una de las líneas de petición de interrupción de forma individual.
Solamente los canales de interrupción que se conectan al bus EISA/ISA pueden ser
programados en el modo sensible al nivel con el propósito de ser compartidos entre varios
dispositivos. Esto significa que IRQ0, IRQ1, IRQ2 e IRQ13 deben programarse sensibles al
flanco. IRQ8 debe programarse sensible al nivel.
Si alguna línea se ha configurado para ser sensible al nivel entonces la solicitud de
interrupción debe ser eliminada antes de que se envíe el comando EOI o se produciría otra
interrupción. Este requerimiento constituye una dificultad para los esquemas de
enmascaramiento virtual de la sección 5.5.3. El problema es que en los algoritmos de
enmascaramiento virtual descritos, el LLIH enmascara la petición de interrupción en el
registro IMR del PIC sólo en los casos en que la IRQ sea indebida (comportamiento
optimista). Si no es el caso, el LLIH no enmascara la IRQ pero tampoco elimina la
condición que provocó la petición en el dispositivo solicitante. Como consecuencia, una
vez que el LLIH envía el EOI (en el caso de EOI explicito) o si se usa EOI automático, la
interrupción se volverá a generar haciendo que el sistema caiga en un lazo infinito de
invocación al LLIH.
Afortunadamente la situación anterior se puede solucionar fácilmente haciendo que en el
caso de que la línea de petición de interrupción sea sensible al flanco el LLIH sitúe
explícitamente la máscara de IRQ. Observe que esta modificación no afecta el tiempo de
conmutación de contexto ya que la máscara sólo se sitúa en caso de ocurrencia de las
interrupciones y no en cada conmutación de contexto. Realizada esta aclaración, en el resto
de este trabajo se supondrá líneas de interrupción activadas por flanco.
5.5.5 Ejemplo de Comportamiento de la emulación con enmascaramiento Virtual
En esta sección se ilustra la operación de la emulación del modelo integrado utilizando el
esquema de emulación mediante enmascaramiento virtual antes descrito. Para ello se
utilizará el mismo ejemplo (conjunto de tareas y secuencia de eventos) que se introdujo en
la sección 5.4.3 para ilustrar la emulación mediante enmascaramiento físico explícito. En
realidad el comportamiento exacto estará en dependencia del mecanismo de
enmascaramiento de la IRQ indebida que se utilice (ver sección 5.5.3.1) por lo que a
continuación se analizarán los tres casos.
5.5.5.1 Enmascarar exclusivamente la IRQ indebida que se produjo
Luis Eduardo Leyva del Foyo 104
La Figura 35 muestra el comportamiento para el caso en que sólo se enmascare la IRQ
indebida que se produjo (caso 1 de la sección 5.5.3.1). La secuencia de eventos del ejemplo
ilustra el peor caso posible de perturbación a la tarea SAT1 que se produce cuando ocurren
todas las IRQs de forma indebida.
Como puede observarse, en este caso cada una de las peticiones de interrupción de los
dispositivos externos (IRQ2 en el instante t3 e IRQ1 en el instante t4) interrumpe a la CPU y
provoca la ejecución del LLIH que inmediatamente se percata que es una interrupción
indebida y enmascara la IRQ correspondiente, señala al objeto de sincronización de
interrupción asociado a la IRQ y retorna inmediatamente a la ejecución de la tarea SAT1
interrumpida (esto ocurre en los instantes t3´ y t4´ para los casos de la IRQ2 y la IRQ1
respectivamente).
Emisión
de la IRQ
por el
dispositivo
externo
Reconocimiento
de la IRQ
en la CPU
Activación
de la HAT
Tasks o la SAT
IRQs
tiempo
prioridad
HAT1
HAT2
SAT2
SAT1
IRQ2
IRQ1
IRQx inhabilitada
Nivel de
prioridad
Leyenda
t1 t2 t3 t3´ t4 t4´ t5" t6" t7" t8"
Figura 35. Enmascaramiento Virtual: Enmascara sólo la IRQ indebida que se produjo.
Con esta variante de emulación las conmutaciones de contextos hacia tareas de mayor
prioridad o expropiaciones (como ocurre en el instante t2) no modifican el nivel de
prioridad de las interrupciones (y por tanto tampoco establecen la máscara de interrupción).
Sólo se producen escrituras de la máscara cada vez que ocurre una interrupción indebida
para enmascararla (instantes t3 y t4) y al finalizar la ejecución de las HATs correspondientes
para desenmascararla (instantes t6” y t7”). Como puede observarse, en el caso de la
secuencia de ejemplo, sólo ocurren cuatro operaciones de escritura de la máscara (en lugar
de las 6 que ocurrieron para la misma secuencia cuando se utilizó enmascaramiento físico
explícito – ver sección 5.4.3) para una disminución del 33% de estas operaciones (en el
peor caso). Como puede apreciarse en la figura, el costo de esta reducción (mejora en el
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 105
comportamiento promedio) es la introducción de perturbaciones pequeñas y acotadas
(intervalos t3-t3´ y t4-t4´) a la ejecución de la tarea SAT1 (empeoramiento del
comportamiento en el peor caso). Sin embargo, debido a que el número (dos en este caso) y
el tamaño de estas perturbaciones están acotados, el sistema continúa exhibiendo un
comportamiento predecible.
5.5.5.2 Enmascarar IRQs con prioridades menores o iguales que la IRQ indebida
La Figura 36 muestra el comportamiento para el caso en que se enmascaren todas las IRQs
con prioridades menores o iguales que la IRQ indebida que se produjo (caso 2 de la sección
5.5.3.1). La secuencia de eventos del ejemplo ilustra el peor caso posible de perturbación a
la tarea SAT1 que se produce cuando ocurren todas las posibles IRQs indebidas en orden
inverso de prioridad (primero la de menor prioridad y luego la de mayor prioridad).
Emisión
de la IRQ
por el
dispositivo
externo
Reconocimiento
de la IRQ
en la CPU
Activación
de la HAT
Tasks o la SAT
IRQs
tiempo
prioridad
HAT1
HAT2
SAT2
SAT1
IRQ2
IRQ1
IRQx inhabilitada
Nivel de
prioridad
Leyenda
t1 t2 t3 t3´ t4 t4´ t5" t6" t7" t8"
Figura 36. Enmascaramiento Virtual: Enmascara IRQs con prioridades menores o
iguales que la IRQ indebida que se produjo.
Para este caso específico, cada una de las peticiones de interrupción de los dispositivos
externos (IRQ2 en el instante t3 e IRQ1 en el instante t4) interrumpe a la CPU y provoca la
ejecución del LLIH que inmediatamente se percata que es una interrupción indebida y
establece físicamente el nivel de prioridad de interrupción correspondiente a la IRQ
indebida. Esto efectivamente enmascara todas las IRQs con prioridades menores o iguales
que la IRQ correspondiente. Posteriormente el LLIH señala al objeto de sincronización de
interrupción asociado a la IRQ y retorna inmediatamente a la ejecución de la tarea SAT1
Luis Eduardo Leyva del Foyo 106
interrumpida (esto ocurre en los instantes t3´ y t4´ para los casos de la IRQ2 y la IRQ1
respectivamente).
Con esta variante de emulación las conmutaciones de contextos hacia tareas de mayor
prioridad o expropiaciones (como ocurre en el instante t2) no actualizan la máscara de
interrupción. Al igual que en el caso anterior, sólo se producen escrituras de la máscara
cada vez que ocurre una interrupción indebida para enmascararla (instantes t3 y t4) y al
finalizar la ejecución de las HATs correspondientes para desenmascararla (instantes t6” y
t7”). Nuevamente, para el caso de la secuencia de ejemplo, sólo ocurren cuatro operaciones
de escritura de la máscara (en lugar de las 6 que ocurrieron para la misma secuencia cuando
se utilizó enmascaramiento físico explícito – ver sección 5.4.3) para una disminución del
33% de estas operaciones (en el peor caso). Sin embargo, la mayoría de las veces ocurrirán
menos aún ya que esto sólo sucede cuando las interrupciones indebidas ocurren en orden
inverso de prioridades (lo cual es improbable). Como puede apreciarse en la figura,
nuevamente el costo de esta reducción (mejora en el comportamiento promedio) es la
introducción de perturbaciones pequeñas y acotadas (intervalos t3-t3´ y t4-t4´) a la ejecución
de la tarea SAT1 (empeoramiento del comportamiento en el peor caso). Sin embargo,
debido a que el número (dos en este caso) y el tamaño de estas perturbaciones están
acotados, el sistema continúa exhibiendo un comportamiento predecible.
5.5.5.3 Enmascarar las IRQs con prioridades menores o iguales que el nivel actual
La Figura 37 muestra el comportamiento para el caso en que se enmascaren todas las IRQs
con prioridades menores o iguales que el nivel de prioridad actual (caso 3 de la sección
5.5.3.1). Nuevamente, la secuencia de eventos del ejemplo ilustra el peor caso posible de
perturbación a la tarea SAT1. En este caso, no importa cual sea la petición de interrupción
que ocurra de forma indebida (IRQ1 o IRQ2), su ocurrencia impedirá que cualquier otra
pueda producirse de forma indebida (hasta tanto finalice la tarea en ejecución en ese
instante).
En la secuencia específica, la IRQ2 sucede inicialmente de forma indebida en el instante t3
interrumpiendo a la CPU y provocando la ejecución del LLIH que inmediatamente se
percata que es una interrupción indebida y establece físicamente el nivel de prioridad (de
interrupción) actual. Esto efectivamente enmascara todas las IRQs que pudieran ocurrir de
forma indebida (IRQ1 e IRQ en el ejemplo). Posteriormente el LLIH señala al objeto de
sincronización de interrupción asociado a la IRQ y (en el instante t3´) retorna
inmediatamente a la ejecución de la tarea interrumpida SAT1. Obsérvese como en este
caso, cuando el dispositivo externo emite la IRQ1 en el instante t4, ésta ya no interrumpe a
la CPU (ya fue enmascarada por el LLIH cuando la IRQ2 ocurrió de forma indebida en t3).
Esta IRQ1 es recordada en el registro IRR del PIC y su emisión a la CPU será demorada
(planificada) hasta tanto sea desenmascarada producto de la disminución del nivel de
prioridad actual al finalizar la ejecución de SAT1 (lo cual ocurre en el instante t5´).
Igual que en las dos variantes anteriores de emulación con enmascarado virtual, las
conmutaciones de contextos hacia tareas de mayor prioridad o expropiaciones (por ejemplo
en el instante t2) no actualizan la máscara de interrupción. Sólo se producen escrituras de la
máscara para enmascarar IRQs, cada vez que ocurre una interrupción de forma indebida.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 107
En la secuencia del ejemplo esto sucederá en el instante t3 (primera escritura de la máscara).
Otra escritura de la máscara (la segunda) se producirá en el instante t5´, al finalizar la
ejecución de la SAT1 cuando el sistema intenta conmutar a la HAT2 (que se había activado
– puesto lista – en t3´), al disminuir el nivel de prioridad hasta la prioridad correspondiente
a la HAT2 se desenmascara la IRQ1 (no la IRQ2) lo que provoca que el PIC le envíe a la
CPU (planifique) la IRQ1 que estaba pendiente provocando la interrupción de la CPU para
ejecutar la HAT1. Obsérvese que esta conmutación hacia la HAT1 es en efecto una
expropiación a la HAT2 y por tanto no provoca una nueva escritura de la máscara (como
ocurriría en el caso de que se usase enmascaramiento físico – ver sección 5.4.3). Es por esto
que ahora la HAT1 se ejecuta con la IRQ1 habilitada.
La última escritura de la máscara (tercera) que se produce en la secuencia de ejemplo
ocurre (en el instante t7´) al finalizar la ejecución de la HAT2 como parte de la disminución
del nivel de prioridad (de interrupción) hasta el nivel correspondiente a la tarea SAT2 que
se reanuda. En este caso, la escritura es tal que vuelve a desenmascarar ambas IRQs.
Emisión
de la IRQ
por el
dispositivo
externo
Reconocimiento
de la IRQ
en la CPU
Activación
de la HAT
Tasks o la SAT
IRQs
tiempo
prioridad
HAT1
HAT2
SAT2
SAT1
IRQ2
IRQ1
IRQx inhabilitada
Nivel de
prioridad
Leyenda
t1 t2 t3 t3´ t4 t5´ t6´ t7´ t8´
Figura 37. Enmascaramiento Virtual: Enmascara IRQs con prioridades menores o
iguales al Nivel de Prioridad Actual
En total, en esta secuencia del ejemplo sólo ocurren tres operaciones de escritura de la
máscara (en lugar de las 6 que ocurrieron para la misma secuencia cuando se utilizó
enmascaramiento físico explícito – ver sección 5.4.3 – o las cuatro que ocurrieron cuando
se utilizaron las dos variantes de emulación del enmascarado virtual anteriores – ver
secciones 5.5.5.1 y 5.5.5.2) para una disminución del 50% con respecto al modo de
emulación con enmascaramiento físico. Para este caso, el costo de esta reducción (mejora
Luis Eduardo Leyva del Foyo 108
en el comportamiento promedio) es la introducción de una sola perturbación pequeña y
acotada (intervalo t3-t3´) a la ejecución de las tareas (empeoramiento mínimo del
comportamiento en el peor caso). Sin embargo, debido a que ahora sólo puede ocurrir una
sola perturbación (para cada tarea) y el tamaño de esta perturbación está acotado, el sistema
continúa exhibiendo un comportamiento predecible. Adicionalmente, la afectación al
comportamiento promedio es la mínima posible.
5.5.6 Análisis de factibilidad con enmascaramiento virtual
Cuando se utiliza enmascarado virtual, el enmascarado de una IRQs sólo puede ocurrir si la
misma se produjo realmente (de forma indebida), mientras que el desenmascarado se
produce sólo, si como parte de una conmutación de contexto (de salida de una actividad), es
necesario habilitar nuevamente a dicha IRQ.
Para las actividades en el conjunto P(i) el peor caso se dará cuando todas las IRQs del
subconjunto H(i) ocurran de forma indebida mientras se estén ejecutando actividades en
P(i) de mayor prioridad que la IRQ correspondiente. En este caso, cada una implicaría una
primera escritura de la máscara como parte de su manejador y una segunda escritura cuando
finalice la actividad en P(i) que fue indebidamente interrumpida por ésta. Sin embargo,
como esta escritura sólo se producirá en el caso de que se haya producido realmente la IRQ,
la misma no se debe asociar a cada conmutación de contexto en P(i); sino que, basta con
asociar dos escrituras de máscara (2δM) a cada posible activación de las actividades en H(i).
En consecuencia, la fracción de utilización Ui
M debido a la interferencia que ejercen las
HAT del conjunto H(i) sobre la tarea ti está dada por:
( )
2 2
j H i
H
J
M p Hj
M
i T
c
U
Donde γ es el tiempo de ejecución del prólogo asociado a las IRQs no deseadas, que es
necesario para registrar su ocurrencia. Además, ahora es necesario tener en cuenta la
perturbación asociada a la posible ejecución de los pequeños prólogos de atención a las
IRQs asociadas a cualquiera de las actividades en los conjuntos S(i) y L(i) (no la actividad
de atención como tal) cuando ellas se producen de forma indebida. Este prólogo se encarga
de enmascarar dicha IRQ. En este caso, sólo hay que contabilizar un enmascaramiento por
cada ocurrencia de IRQ no deseada, ya que ninguna conmutación de contexto de
actividades en P(i) implicarán un desenmascarado de cualquiera de las IRQs asociadas a
actividades en S(i) o L(i). Sin embargo, el número de veces que puede ejecutarse este
prólogo depende del modo en que se haga el enmascaramiento (según se describió en la
sección 5.5.3.1). Sea γ es el tiempo de ejecución del prólogo asociado a las IRQs no
deseadas, necesario para recordar su ocurrencia, entonces:
1) Para los casos en que se enmascare sólo la IRQ actual o todas las IRQ con prioridades
menores o iguales que la IRQ actual (o sea, casos 1 y 2 de la sección 5.5.3.1), entonces
en el peor caso, cada una de las IRQ del conjunto S(i) L(i) puede ocurrir a lo sumo
una vez. En consecuencia, la ecuación (9) puede escribirse como:
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 109
( ( ) ( )) ( )
( ) ( ) 2 2
j H i
H
J
M p Hj
j P i H i j
j
i
M
P i
i T
c
T
C
T
C S i L i
U
(14)
A partir de la ecuación (14) podemos establecer que la disminución en la utilización
Uloss = Ui
PI* debido a la sobrecarga del modelo integrado con enmascaramiento virtual
(empleando el esquema de enmascarado 1 ó 2 de la sección 5.5.3.1), será:
( )
* ( ) ( ) 2 2
j H i
H
J
p M
i
M
PI
i T T
S i L i
U
(15)
Observe que aunque los esquemas de enmascaro 1 y 2 de la sección 5.5.3.1 tiene el
mismo peor caso, en el esquema 2 este peor caso es muy poco probable y en general
tendrá un comportamiento promedio mejor que el esquema 1.
2) Para el caso en que se establezca la máscara que corresponde con la prioridad actual del
sistema PC (o sea, el caso 3 de la sección 5.5.3.1), entonces sólo puede ocurrir una sola
IRQ no deseada en el conjunto S(i) L(i). En consecuencia, la ecuación (9) puede
escribirse como:
( ( ) ( )) ( )
2 2
j H i
H
J
M p Hj
j P i H i j
j
i
M
P i
i T
c
T
C
T
C
U
(16)
A partir de la ecuación (15) podemos establecer que la disminución en la utilización
Uloss = Ui
PI* debido a la sobrecarga del modelo integrado con enmascaramiento virtual
(empleando el esquema de enmascarado 3 de la sección 5.5.3.1), será:
( )
* 2 2
j H i
H
J
p M
i
M
PI
i T T
U
(17)
Obsérvese que, a diferencia del mecanismo tradicional, consistente en utilizar una ISR
mínima postergando el servicio al nivel de tarea (subsecciones 4.2.1.1 y 4.2.2), este
esquema optimista es temporalmente determinista. Ahora se introduce nuevamente una
inversión de prioridad debido a una pequeña perturbación debido a la ejecución del prólogo
de una interrupción no deseada (dada por γ+δM
), pero como demuestran las ecuaciones (15
ó 17), esta inversión de prioridad es acotada. Este esquema garantiza una administración de
interrupciones predecible con una perdida en la utilización muy pequeña. También observe
que ahora Ui
PI* (Ecuación 14) sólo depende de las HATs en el conjunto H(i) y no de las
tareas activadas por software (como sucede en la Ecuación 12), haciendo al sistema más
escalable
Como un comentario general, vale la pena observar que el esquema de protección optimista
es un caso específico de una técnica de optimización más general utilizada con frecuencia
en los sistemas operativos de propósito general conocida como técnicas perezosas (“lazy
Luis Eduardo Leyva del Foyo 110
techniques”), y que consiste en evitar la ejecución de operaciones costosas hasta que sean
absolutamente necesarias. Aunque estas técnicas se han utilizado para optimizar el caso
más frecuente, en este caso su aplicación a los sistemas operativos de tiempo real nos ha
permitido disminuir la pérdida en la utilización en el peor caso.
5.6 Protocolo de enmascarado implícito y desenmascarado explícito
Una alternativa simple al modelo integrado aquí propuesto que también puede enfrentar el
no determinismo introducido por las interrupciones sin necesidad de integrar el espacio de
prioridades es el empleo de lo que denominamos protocolo de enmascaramiento
implícito y desenmascaramiento explícito. Con esta técnica, el núcleo sitúa un LLIH
común a todas las interrupciones que hace el reconocimiento inmediato de la interrupción
al PIC (EOI) y acto seguido enmascara la petición de interrupción, evitando con ello
ocurrencias adicionales de la misma petición. Luego, activa la ejecución de una tarea de
servicio de interrupción o IHT (“Interrupt Handler Task”) la cual se planifica igual que el
resto de las demás tareas según la prioridad que le corresponda por el planificador (de
tiempo real) del sistema. La IHT tiene entonces la responsabilidad de desenmascarar de
forma explícita la petición de interrupción una vez que le haya dado servicio mediante un
servicio de acuse de recibo que brinda el núcleo con ese propósito.
5.6.1 Análisis de Factibilidad
La operación de acuse de recibo (desenmascarado) de interrupción dentro de la IHT
funciona como petición (“request”) de una interrupción adicional qué sólo pueden ocurrir
en respuesta (“reply”) a esta petición. En consecuencia, con esta técnica, se consigue un
efecto similar al empleo del esquema integrado con enmascaramiento virtual y el caso 1 de
enmascaramiento. O sea, a lo sumo puede ocurrir una sola instancia de cada una de las IRQ
asociadas a IHT de menor prioridad que la tarea ti (que serían IRQ no deseadas). Con lo
cual se consigue acotar la inversión de prioridad en el peor caso. Sin embargo, en este caso
se añade la sobrecarga de una escritura de máscara más el envío del EOI a la latencia de
interrupción de todas las IRQs y adicionalmente se añade una segunda escritura de máscara
al tiempo de cómputo de cada una de ellas.
SeaδE
OI el tiempo de cómputo asociado al envío del EOI al PIC, entonces la ecuación (9)
puede escribirse como:
( ( ) ( )) ( )
( ) ( ) 2 2 2
j H i
H
J
EOI M p Hj
j P i H i j
j
i
M EOI
P i
i T
c
T
C
T
C S i L i
U
Por tanto, la pérdida en la utilización Uloss = Ui
PI* debido al empleo del protocolo de
enmascaramiento explícito y desenmascaramiento explícito esta dada por:
( )
* ( ) ( ) 2 2 2
j H i
H
J
p M EOI
i
M EOI
PI
i T T
S i L i
U
(18)
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 111
Como puede observarse (además del incremento en la latencia de interrupción debido al
enmascaramiento de la IRQ como parte del LLIH), la sobrecarga introducida en términos
de pérdida de utilización en este caso es superior al sobrecarga introducida por el esquema
integrado con enmascaramiento virtual (ecuaciones 15 y 17).
Lo interesante de esta última técnica es que, con el propósito de hacer que las IHT fuesen
completamente independientes del hardware de interrupciones del sistema, esta fue
implementada en el micro-núcleo L4 como parte del proceso de portarlo a arquitecturas
diferentes de la IA32 para la cual fue creado originalmente [27]. El resultado es que, como
efecto colateral, este micro-núcleo (a pesar de no estar diseñado para aplicaciones de
tiempo real [76]) consiguió acotar la inversión de prioridad de las interrupciones.
Sin embargo, esta conversión no es gratis ya que el acuse de recibo y enmascarado
automático de la petición de interrupción como parte del FLIH trae consigo un aumento
significativo en la latencia de interrupción y en la sobrecarga operativa (“overhead”).
5.7 Diseño detallado del HAL para sistemas PC compatibles
En esta sección se describe la lógica de cada uno de los servicios de soporte de
interrupciones del HAL para sistema PC compatibles, así como se muestran los seudocódigos
de cada uno de los mismos
5.7.1 Tratamiento a las interrupciones dentro del INTHAL
Como se planteo en la sección 5.2, para poder llevar a cabo su tarea el INTHAL tiene que
capturar todas las IRQs. Para ello durante la inicialización el INTHAL (servicio
initIrqHardware(…)) se encarga de situar la tabla de vectores de interrupción de la CPU
de forma que todas las IRQ apunten a una entrada dentro de una la Tabla de Entradas de
IRQs del INTHAL. Esta disposición se muestra en la Figura 35. Como se aprecia en el
esquema, esta tabla, situada en la sección de código del INTHAL posee una entrada para
cada una de las IRQs de hardware (un total de 15 entradas en un sistema PC-AT). En
realidad, cada una de estas entradas posee un pequeño código que se encarga de invocar a
un manejador de interrupción de bajo nivel LLIH (“Low Level Interrupt Handler”)
pasándole como parámetro la IRQ correspondiente.
En realidad, el tratamiento que le da el INTHAL a las IRQs está en dependencia de su
estado (capturada o ignorada – ver el diagrama de estado de la Figura 21). Si la IRQ está en
el estado ignorada, entonces el punto de entrada del LLIH es PANIC_ENTRY; si está
capturada, el punto de entrada del LLIH es CAPTURED_ENTRY. Al cargarse el sistema,
todas las entradas de la Tabla de Entradas de IRQ están configuradas para saltar al LLIH
PANIC_ENTRY( irq ). Posteriormente la ejecución de los servicios enableIrq() y
disableIrq() provocan las transiciones de estado que modifican el LLIH asociado a cada
IRQ.
Adicionalmente, el HAL posee varios modos de emulación los cuales se resumen en la
Figura 39. Cada modo de emulación posee algoritmos diferentes para los Manejadores de
IRQ de Bajo Nivel. Estos se configuran durante la inicialización del INTHAL.
Luis Eduardo Leyva del Foyo 112
IRQ0
IRQ1
IRQ2
IRQ3
IRQ4
.
..
IRQ14
IRQ15
Tabla de Vectores de
Interrupción de la CPU
Tabla de Entradas de
de IRQ del INTHAL
Manejadores de IRQ
de Bajo Nivel (HAL)
PANIC_ENTRY
CAPTURED_ENTRY
REFLECTED_ENTRY
CAPT_REFL_ENTRY
IRQ00_ENTRY:
push bx
mov bl00h
JMP
IRQ15_ENTRY:
push bx
mov bl 01h
JMP
IRQ01_ENTRY:
push bx
mov bl 01h
JMP
Figura 38. Flujo de control de las interrupciones a través del INTHAL
Descripción
Código EndIRQ() Modo EOI EOI EndIRQ()
0 0 0 Explícito Soportado
1 0 1 Automático Soportado
2 1 0 Explícito No Soportado
3 1 1 Automático No Soportado
Figura 39. Modos de Emulación del INTHAL
5.7.2 Estructuras de Datos para Mantener el Estado del HAL de Interrupciones
El INTHAL mantiene el estado del VCPIC mediante un conjunto de variables internas cada
una de las cuales se especifican a continuación.
Se mantiene los siguientes arreglos de 16 elementos, uno por cada IRQ del sistema:
IRQ_Priority: arreglo de bytes (8 bits) con la prioridad de cada IRQ del sistema. La
IRQ2, que conecta en cascada al segundo 8259, se pone en prioridad máxima (255).
Con esto se consigue que siempre esté habilitada y permita el paso de las interrupciones
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 113
desde el segundo 8259, sin tener que hacer una distinción especial para ella en los
algoritmos internos.
IRQ_Mask: arreglo de palabras (16 bits), cada una de las cuales mantiene la máscara a
situar en los registros IMR de ambos 8259 en el momento de la ocurrencia de la IRQ
correspondiente. La máscara posee un “0” en los bits correspondientes a las IRQ de
mayor prioridad y “1” en los bits correspondientes a las IRQ de prioridad menor o igual
(incluyéndose a la misma IRQ).
OLD_Level: arreglo de bytes (8 bits) con el nivel de interrupción activo cuando ocurrió
la IRQ particular.
OLD_Mask: arreglo de palabras (16 bits) con la máscara de interrupción activa cuando
ocurrió la IRQ particular.
Además se mantienen las siguientes variables:
Virtual_Mask_Mode: Indicador que indica si se está operando en modo de
enmascarado virtual (TRUE) u físico (FALSE).
IRQ_Level: variable de tipo byte que conserva el nivel de prioridad actual del sistema.
Logical_Mask: variable de tipo palabra que contiene la máscara de interrupción
correspondiente al IRQ_Level.
Fisical_Mask: variable de tipo palabra que contiene la máscara de interrupción que está
situada realmente en los registros IMR de los 8259s. En el modo de enmascarado físico
siempre va a coincidir con Logical_Mask. Sin embargo, en el modo de enmascarado
virtual puede no coincidir.
5.7.3 Seudo-código de los servicios fundamentales del INTHAL
5.7.3.1 Inicialización y Terminación del INTHAL
Los servicios initIrqHardware(minDefault, maxDefault, eoiMode, maskMode) y
restoreIrqHardware() se encargan de inicializar y restaurar el hardware de interrupciones.
En el caso del servicio de inicialización su función es establecer los valores iniciales de las
variables de estado interna e iniciar la tabla de vectores de interrupción según se describió
en la secciones 5.7.1 y 5.7.2.
5.7.3.2 Servicios de Administración de Prioridaddes
Los servicios de administración de las prioridades de interrupción son quizás los más
importantes del INTHAL para la implantación del VCPIC. Esos servicios son los que
logran la ilusión de que a las IRQs se le puedan asignar prioridades de forma dinámica y
dentro del mismo espacio de prioridades del planificador del núcleo. Este subconjunto está
conformado por los servicios de interfaz setIrqPriority() y setIrqLevel(); así como, por
los servicios auxiliares Set8259IMR() y setIRQMask().
Luis Eduardo Leyva del Foyo 114
Servicios auxiliares: Set8259IMR(mask) y setIRQMask(mask)
Es conveniente contar con un servicio auxiliar set8259IMR(…) que debe ser invocado
cada vez que es necesario situar la máscara en el hardware de interrupción (registros IMR
de ambos 8259). Mediante ello es posible mantener una variable en memoria
(Fisical_Mask) con el valor actual de los registros de máscara de forma que se pueda evitar
la costosa operación de E/S necesaria para establecer la máscara siempre que la nueva
máscara a situar coincida con la que ya está presente.
Adicionalmente, para el soporte del enmascaramiento virtual, es conveniente tener un
segundo servicio setIRQMask(…) que va a ser invocado siempre que se quiere establecer
la máscara correspondiente con determinado nivel de prioridad.
En la Figura 40 se muestra el algoritmo del servicio set8259IMR(mask). El servicio
primero verifica que la máscara física sea diferente de la máscara que se desea establecer.
Si ello se cumple, establece realmente la máscara en los registros IMR de ambos 8259 y
actualiza los valores de las variables de memoria Logical_Mask y Fisical_Mask.
Set8259IMR (mask) {
Si ( mask Fisical_Mask ) {
Logical_Mask = mask
Fisical_Mask = mask
Registros IMR de ambos 8259 mask
}
Figura 40. Algoritmo de Set8259IMR()
setIRQMask (mask) {
Si ( VirtualMaskMode = TRUE) {
Si ( Fisical_Mask AND ( NOT mask ) )
Set8259IMR(mask)
Sino
Logical_Mask = mask
}
Sino {
Set8259IMR (mask)
}
}
Figura 41. Algoritmo de setIRQMask()
En la Figura 41 se muestra el algoritmo del servicio setIRQMask(mask). El
comportamiento de este servicio está en dependencia del modo de enmascaramiento (físico
o virtual) el cual se conserva en la variable de estado Virtual_Mask_Mode:
En el caso de enmascaramiento físico (Virtual_Mask_Mode = FALSE) este servicio
simplemente invoca a Set8259IMR() para establecer realmente la máscara en ambos
8259.
Administración de Interrupciones en Sistemas Operativos de Tiempo Real 115
En el caso de enmascaramiento virtual (Virtual_Mask_Mode = TRUE), sólo sitúa la
máscara si ello implica habilitar (desenmascarar) una IRQs. En caso de que la nueva
máscara implique la inhabilitación (enmascarado) de una IRQ entonces sólo se
actualiza el valor de la máscara lógica (Logical_Mask).
Puede observarse que en todo instante Logical_Mask contiene el valor de la máscara que
se corresponde con el nivel de prioridad actual (irqLevel). En el caso en que se esté
operando en el modo de enmascaramiento físico este valor siempre va a ser igual al valor
de los registros IMR de ambos 8259 y al valor de Fisical_Mask. Por el contrario, si se
opera en modo de enmascaramiento virtual el valor de Logical_Mask puede coincidir o no
con el valor de Fisical_Mask (y de los registros IMR de ambos 8259). Sin embargo, en este
modo siempre se tiene que cumplir que Fisical_Mask sea menos o igual de restrictiva que
Logical_Mask. En otras palabras, siempre se tiene que cumplir la siguiente propiedad (o
invariante):
( ┐Logical_Mask & Fisical_Mask ) = 0
Servicio setIrqPriority ( IRQ, PRIORITY )
La Figura 42 muestra el algoritmo de setIrqPriority(). Este servicio permite establecer el
nivel de prioridad de una IRQ. Es su responsabilidad hacer la correspondencia entre las
prioridades asignadas a cada una de las IRQs (dentro del espacio de prioridades del
sistema) y el valor correspondiente de la máscara a situar en el hardware de interrupciones
(registros IMR de ambos 8259).
Como parte de esta tarea, setIrqPriority() mantiene los arreglos IRQ_Priority e
IRQ_Mask ambos con una entrada por cada IRQ posible en el sistema. El primer arreglo
conserva la prioridad actual de cada una de las IRQs (en el espacio de prioridades del
núcleo). En cada invocación setIrqPriority() actualiza la entrada correspondiente a la IRQ
a la que se le está estableciendo la prioridad. Luego, a partir de la nueva configuración de
prioridades reflejada en el arreglo obtiene la máscara asociada a cada una de las IRQ. Estas
máscaras se conservan en el segundo arreglo. Por último, este servicio invoca
setIRQMask() para actualizar la máscara de interrupción (física y lógica) en los casos en
que la IRQ a la que se le está estableciendo (modificando) la prioridad pase de habilitada a
inhabilitada o viceversa.
Luis Eduardo Leyva del Foyo 116
setIrqPriority (IRQ, Priority) {
IRQ_Priority[IRQ] Priority /* actualiza la prioridad
*/
t_IRQMask 0
Para_( t_IRQ 0..IRQ_NUMBERs-1 ) {
Si ( IRQ_Priority[t_IRQ] < Priority) {
Pone 0 en bit IRQ de IRQ_Mask[t_IRQ]
Pone 1 en bit t_IRQ de t_IRQMask
} Si (
IRQ_Priority[t_IRQ] =
Priority )
{
Pone 1 en bit IRQ de IRQ_Mask[t_IRQ]
Pone 1 en bit t_IRQ de t_IRQMask
} Si (
IRQ_Priority[t_IRQ] >
Priority) {
Pone 1 en bit IRQ de IRQ_Mask[t_IRQ]
Pone 0 en bit t_IRQ de t_IRQMask
}
} IRQ_Mask[IRQ]
t_IRQMask;
/* actualizar máscaras de 8259s */
t_IRQMaskBit (1
PUERTO SERIAL
Uno de los defectos de los puertos serie iniciales era su lentitud en comparación con los puertos paralelos, sin embargo, con el paso del tiempo, están apareciendo multitud de puertos serie con una alta velocidad que los hace muy interesantes ya que tienen la ventaja de un menor cableado y solucionan el problema de la velocidad con un mayor apantallamiento; son más baratos ya que usan la técnica del par trenzado; por ello, el puerto RS-232 e incluso multitud de puertos paralelos están siendo reemplazados por nuevos puertos serie como el USB, el Firewire o el Serial ATA. Los puertos serie sirven para comunicar al ordenador con la impresora, el ratón o el módem; Sin embargo, específicamente, el puerto USB sirve para todo tipo de periféricos, desde ratones, discos duros externos, hasta conexión bluetooth. Los puertos SATA (Serial ATA): tienen la misma función que los IDE, (a éstos se conecta, la disquetera, el disco duro, lector/grabador de CD y DVD) pero los SATA cuentan con mayor velocidad. Un puerto de red puede ser puerto serie o puerto paralelo.
Los puertos serie se usan frecuentemente en estas áreas porque son sencillos, baratos y permiten la interoperabilidad entre dispositivos
Simplex
En este caso el emisor y el receptor están perfectamente definidos y la comunicación es unidireccional. Este tipo de comunicaciones se emplean, usualmente, en redes de radiodifusión, donde los receptores no necesitan enviar ningún tipo de dato al transmisor.
Duplex, half duplex o semi-duplex
En este caso ambos extremos del sistema de comunicación cumplen funciones de transmisor y receptor y los datos se desplazan en ambos sentidos pero no de manera simultánea. Este tipo de comunicación se utiliza habitualmente en la interacción entre terminales y una computadora central.
Full Duplex
El sistema es similar al duplex, pero los datos se desplazan en ambos sentidos simultáneamente. Para que sea posible ambos emisores poseen diferentes frecuencias de transmisión o dos caminos de comunicación separados, mientras que la comunicación semi-duplex necesita normalmente uno solo. Para el intercambio de datos entre computadores este tipo de comunicaciones son más eficientes que las transmisiones semi-dúplex.
Antes de cada byte de datos, los puertos serie envían un bit de comienzo, el cual es un único bit con un valor de 0. Después de cada byte de datos, envía un bit de parada para señalar que el byte está completo. También envía un bit de paridad.
Los puertos serie, también llamados puertos de comunicación (COM), son bi-direccionales. La comunicación bi-direccional permite a cada dispositivo recibir datos a la vez que los transmite. Los dispositivos serie usan pines diferentes para el recibir y enviar datos - usar los mismos pines significaría que la comunicación estaría limitada a half-duplex, y que la información viajaría en una sola dirección a la vez. Usar pines diferentes permite una comunicación full-duplex, y puede viajar en ambos sentidos.
Los puertos serie delegan en un controlador o chip especial llamado UART (Universal Asynchronous Receiver/Transmitter), para funcionar correctamente. El chip UART coge la salida en paralelo del bus del sistema y la transforma en una forma serie para que se transmita por el puerto serie. Para que funcionen más rápido, muchos chips UART tiene integrado un buffer de 16 a 64 Kilobytes en su interior. Este buffer permite al chip hacer un caché de datos mientras está procesando los datos.
La conexión serie
La conexión externa de un puerto serie puede ser de nueve pines o de 25 pines. Originalmente, el uso principal de un puerto serie era conectar un modem a un ordenador. Un aspecto importante de las comunicaciones serie es el concepto del control de flujo. Esto es la habilidad de un dispositivo de decirle a otro dispositivo que pare de enviar datos por un rato. Los comandos RTS (Request to Send), CTS (Clear To Send), DTR (Data Terminal Ready) y DSR (Data Set Ready) son utilizados para habilitar el control de flujo.
Con un ejemplo podemos ver mejor como funciona el control de flujo. Tienes un modem que se comunica a 56 Kbps. La conexión serie entre tu ordenador y tu modem transmite a 115 Kbps, lo cual es el más de la mitad. Esto significa que tu modem está recibiendo más datos viniendo de tu ordenador, que lo que puede transmitir por la línea de teléfono. Incluso, aunque el modem tuviera un buffer de 128 K para almacenar datos, se quedaría sin espacio en el buffer rápidamente y no sería capaz de funcionar adecuadamente con todo ese flujo de datos.
Con control de flujo, el modem puede parar el flujo de datos de tu ordenador antes de que desborde el buffer del modem. El ordenador está constantemente enviando una señal en el pin RTS, y comprobando si hay señal en el pin CTS. Si no hay una respuesta del CTS, el ordenador para de enviar datos, esperando al CTS para reanudar los datos. Esto permite al modem mantener el flujo de datos de manera fluida.
Puerto serial
Los puertos seriales (también llamados RS-232, por el nombre del estándar al que hacen referencia) fueron las primeras interfaces que permitieron que los equipos intercambien información con el "mundo exterior". El término serial se refiere a los datos enviados mediante un solo hilo: los bits se envían uno detrás del otro (consulte la sección sobre transmisión de datos para conocer los modos de transmisión).
Originalmente, los puertos seriales sólo podían enviar datos, no recibir, por lo que se desarrollaron puertos bidireccionales (que son los que se encuentran en los equipos actuales). Por lo tanto, los puertos seriales bidireccionales necesitan dos hilos para que la comunicación pueda efectuarse.
La comunicación serial se lleva a cabo asincrónicamente, es decir que no es necesaria una señal (o reloj) de sincronización: los datos pueden enviarse en intervalos aleatorios. A su vez, el periférico debe poder distinguir los caracteres (un carácter tiene 8 bits de longitud) entre la sucesión de bits que se está enviando.
Ésta es la razón por la cual en este tipo de transmisión, cada carácter se encuentra precedido por un bit de ARRANQUE y seguido por un bit de PARADA. Estos bits de control, necesarios para la transmisión serial, desperdician un 20% del ancho de banda (cada 10 bits enviados, 8 se utilizan para cifrar el carácter y 2 para la recepción).
Los puertos seriales, por lo general, están integrados a la placa madre, motivo por el cual los conectores que se hallan detrás de la carcasa y se encuentran conectados a la placa madre mediante un cable, pueden utilizarse para conectar un elemento exterior. Generalmente, los conectores seriales tienen 9 ó 25 clavijas y tienen la siguiente forma (conectores DB9 y DB25 respectivamente):
Un PC posee normalmente entre uno y cuatro puertos seriales.
Velocidad de transmisión ("Connection speed") es la cantidad de datos transmitidos en unidad de tiempo. Se expresa en bits por segundo (bps). En las transmisiones serie a través de líneas telefónicas, en las que se emplean módems ([pic] H11.1) era frecuente utilizar como medida de velocidad el Baudio ("Baud rate"), en honor de Emile Baudot, al que ya hemos hecho referencia [1b]. Baudio se define como el número de veces que cambia la portadora en un segundo. La velocidad que puede emplearse depende en gran medida de la calidad del medio
de transmisión (calidad de la línea), que si (como es frecuente) se trata de líneas telefónicas, depende a su vez de la distancia.
Los primeros dispositivos serie operaban a velocidades muy bajas, del orden de 110 a 1200 baudios [2]. Las comunicaciones telefónicas serie actuales están muy cerca del máximo teórico que pueden soportar los pares de cobre utilizados en la telefonía estándar. Además, para aumentar el rendimiento de la comunicación se utilizan técnicas de compresión de los datos a transmitir, y velocidades variables, que pueden ser negociadas entre los equipos que comunican en función del estado de la línea en cada momento.
§3.2 Longitud del carácter ("Char length"). Se han utilizado caracteres de 5, 6, 7 y 8 bits, aunque actualmente los datos son enviados como caracteres ASCII, por lo que pueden utilizarse 7 u 8 bits según se trate del juego de caracteres US-ASCII o el extendido ([pic] E2.2.1a). El conjunto de bits que componen un carácter se denominan bits de dato ("Data bits")
§3.3 Paridad ("Parity"). Para poder comprobar la calidad de la transmisión se suele utilizar un sistema de control de paridad que añade un bit a los bits de datos. Los sistemas utilizados son:
• Paridad par ("Even")
• Paridad impar ("Odd")
• Paridad marca ("Marck")
• Paridad espacio ("Space")
• Sin paridad (no se añade ningún bit de paridad al datagrama)
Los sistemas de paridad par e impar se ha explicado al tratar de la memoria ([pic] H5.3); ambos métodos cuentan el número de unos contenidos en los bits de datos y añade un uno o un cero según el resultado. Por su parte la paridad Mark indica que se incluirá siempre una marca (bit de valor "1") como bit de paridad, mientras que la paridad Space añade siempre un espacio ("0"). Evidentemente estos dos últimos sistemas no aportan absolutamente ninguna información, por lo que son usados muy raramente.
§3.4 Bits de parada ("Stop bits"). Después que se envía un carácter se envía un bits de parada, que tienen el valor "1" (marca); la duración de este bit puede ser 1, 1.5 o 2 periodos.
§4 Características eléctricas
Como hemos señalado, las normas y terminología de las comunicaciones serie están muy influenciadas por sus orígenes telegráficos. Esto incluye algunas de las definiciones utilizadas por la norma RS-232.
Una curiosidad de esta norma es que la transmisión de los caracteres ASCII se realiza empezando por el bit menos significativo. Puesto que estamos acostumbrados a representarlos de derecha a izquierda (empezando por el más significativo), podría decirse que los bits son transmitidos al revés.
Los datos se transmiten en binario, pero no es frecuente referirse a ceros y unos como en la informática convencional, sino a espacios y marcas.
En la figura 1 se muestran los niveles de tensión correspondientes a las salidas. Como puede verse, la lógica utilizada es poco convencional, utiliza una lógica bipolar con tensiones negativas para los "1" lógicos [6].
En la figura 2 se muestran los niveles correspondientes a las entradas. Puede verse que su espacio de transición es más reducido que para las salidas.
El puerto serial se constituye como una de las más básicas conexiones externas a un computador, y aunque hoy en día la más utilizada es su forma USB, el puerto serial ha estado junto a nuestros computadores por más de veinte años. Su principal función es enviar y recibir datos, bit por bit, y a modo de ejemplo, se puede mencionar entre ellos el puerto de los antiguos modelos del teclados y modems.
Grosso modo, un puerto serial posee un conector estándar y trabaja con protocolo que permiten la conexión de dispositivos al computador. Estos puertos son denominados seriales debido a que este tipo de puertos serializa la información, en otras palabras, toma un byte de datos y transmite cada uno de los 8 bits uno a uno.
Los puertos seriales se conocen también con el nombre de puertos de comunicación o COM, y tienen la característica de ser bidireccionales. Ésta característica permite a cada uno de estos dispositivos tanto recibir como enviar datos. Su normal funcionamiento depende de un chip especial denominado UART debido a las siglas en inglés para “Universal Asynchronous Reciever/Transmitter”. Este chip controlador toma la salida paralela del bus del computador y lo convierte en forma serial, lo que permite la transmisión de los datos a través del puerto.
Dentro de sus principales ventajas se encuentra la necesidad de sólo un cable para poder transmitir los 8 bits, sin embargo, se demora 8 veces más en realizar esta transmisión que si contáramos con 8 cables, como sucede con un puerto paralelo. Estos últimos son creación más nueva, por lo que han sido fabricados para un funcionamiento más rápido y eficiente, lo que hace pensar que de aquí a algún tiempo más reemplazarán por completo a los puertos serie. No obstante, la aparición de los puertos USB crece con fuerza y amenaza también la existencia de los puertos paralelos, por su mayor comodidad y eficacia.
[pic] [pic] [pic]
Registros en Microprocesadores.
En microprocesadores, un registro es una porción de memoria ultrarrápida, de poca capacidad e integrado al microprocesador, que permite almacenar y acceder datos o micro órdenes usadas frecuentemente. Se emplean para aumentar la velocidad de ejecución de los programas.
La mayoría de las arquitecturas de computadora emplean registros, moviendo datos desde la memoria principal hacia los registros, se opera sobre éstos, y el resultado es movido nuevamente a la memoria principal.
Existen múltiples registros y se dividen en
• REGISTROS VISIBLES AL USUARIO
• REGISTROS DE SEGMENTO
• REGISTROS DE CONTROL
REGISTROS VISIBLES AL USUARIO
• Registró de propósito general (GPR o General Purpose Registers): permiten almacenar tanto datos como direcciones. La mayoría de las computadoras modernas emplean este tipo de registros.
Existen 4 registros denominados AX, BX, CX y DX que en realidad tienen asignados usos característicos, aunque pueden ser utilizados a discreción para cualquier cosa que necesitemos.
• AX es denominado acumulador; suele contener uno de los operandos que intervienen en las operaciones aritméticas y lógicas, y después de esta, el resultado de la operación. En general las instrucciones que trabajan con este registro (o su mitad inferior) tienen un micro código más simple que la misma instrucción ejecutada con otro registro.
• BX es el registro base, suele contener la dirección de inicio de una tabla de valores.
• CX es denominado contador. Las instrucciones de bucle (LOOP) utilizan este registro como contador.
• DX es un registro de datos, multiuso. Se utiliza en operaciones de multiplicación y división junto con AX. En operaciones de entrada/salida de puertos IN/OUT, su mitad inferior DL, contiene el número de puerto.
Aunque estos cuatro registros son de 16 bits (como los 10 restantes) , en caso necesario pueden ser utilizados en dos mitades (nibbles), "High" y "Low", de 8 bits, con lo que puede considerarse que existen 12 registros de uso general (no simultáneos), los anteriores y sus mitades: AH; AL; BH; BL; CH; CL; DH y DL.
DATOS:
SOLO SE EMPLEAN PARA ALMACENAR Y NO PARA CALCULAR UNA DIRECCION DE OPERANDO.
DIRECCIÓN:
PUEDEN SER DE PROPOSITO GENERAL, SON DESIGNADOS A UN MODO DE DIRECCIONAMIENTO EN PARTICULAR.
• APUNTADORES DE SEGMENTO:
• REGISTRO INDICE
• APUNTADOR DE STACK
CODIGOS DE CONDICIÓN (BANDERAS)
SON BITS PUESTOS POR EL HARDWARE DE LA CPU COMO EL RESULTADO DE OPERACIONES
Los registros de banderas sirven parar indicar el estado actual de la maquina y el resultado del procesamiento, Cuando algunas instrucciones piden comparaciones o cálculos aritméticos cambian el estado de las banderas.
Las banderas están en el registro de banderas en las siguientes posiciones:
bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Las banderas más comunes son las siguientes:
OF (Over flow flag, desbordamiento). Indica el desbordamiento de un bit de orden alto (mas a la izquierda) después de una operación aritmética.
DF (Direction flag, Direccion). Designa la dirección hacia la izquierda o hacia la derecha para mover o comparar cadenas de caracteres.
IF (Interruption flag, Interrupcion). Indica que una interrupción externa, como la entrada desde el teclado sea procesada o ignorada.
TF (Trap flag, Trampa). Examina el efecto de una instrucción sobre los registros y la memoria. Los programas depuradores como DEBUG, activan esta bandera de manera que pueda avanzar en la ejecución de una sola interrupción a un tiempo.
SF (Sign flag, Signo). Contiene el signo resultante de una operación aritmética (0=positivo y 1= negativo).
ZF (Zero flag, Zero). Indica el resultado de una operación aritmética o de comparación (0= resultado diferente de cero y 1=resultado igual a cero).
AF (Auxiliary carry flag, Acarreo auxiliar). Contiene un acarreo externo del bit 3 en un dato de 8 bits, para aritmética especializada
PF (Parity flag, Paridad). Indica paridad par o impar de una operación en datos de ocho bits de bajo orden (mas a la derecha).
CF (Carry flag, Acarreo). Contiene el acarreo de orden mas alto (mas a la izquierda) después de una operación aritmética; también lleva el contenido del ultimo bit en una operación de corrimiento o rotación.
Registros de segmento
Se dispone de cuatro registros que sirven para contener las direcciones de otros tantos segmentos (zonas de 64 KB de memoria). Utilizándolos en conjunción con otros registros que señalan las direcciones concretas dentro de estos segmentos (los desplazamientos), permiten manejar la totalidad de la memoria direccionable (el bus de direcciones es de 20 bits). Ver al respecto el epígrafe "Direccionamiento segmentado".
• Segmento de código CS ("Code segment"). Señala la dirección del segmento de código del programa que se está ejecutando.
• Segmento de datos DS ("Data segment"). Señala la dirección del segmento de datos del programa en ejecución.
• Segmento de pila SS ("Stack segment"). Señala la dirección del segmento donde está la pila del programa.
• Segmento extra ES ("Extra segment"). Es un segmento auxiliar a los anteriores, se utiliza para señalar espacio extra en alguno de los segmentos o para almacenar momentáneamente direcciones intermedias.
Nota: Puede ocurrir que programas pequeños utilicen el mismo segmento para el código, los datos y la pila
Registro índice.
Los registros SI y DI están disponibles para direccionamientos indexados y para sumas y restas. Que son la operaciones de punta.
Registro SI.
El registro índice de 16 bits es requerido por algunas operaciones con cadenas (de caracteres). En este contexto, el SI está asociado con el registro DS. Los procesadores 80386 y posteriores permiten el uso de un registro ampliado a 32 bits, el ESI.
Registro DI.
El registro índice destino también es requerido por algunas operaciones con cadenas de caracteres. En este contexto, el Di está asociado con el registro ES. Los procesadores 80386 y posteriores permiten el uso de un registro ampliado a 32 bits, el EDI.
Registros de puntero
Son 5 registros destinados a contener direcciones; estas direcciones son desplazamientos dentro de los segmentos indicados por los registros de segmento
• El primero, denominado indistintamente puntero de instrucción IP ("Instrucción pointer") y contador de programa PC ("Program counter"), indica el desplazamiento (dentro del segmento de código CS) de la próxima instrucción a ejecutar.
• El puntero de pila SP ("Stack Pointer"), señala el desplazamiento del final de la pila dentro del segmento de pila SS. En caso necesario la pila puede crecer a partir de este punto, de forma que por ejemplo, una nueva invocación de función creará un nuevo registro de activación que comenzará en este punto.
• El puntero base BP ("Base pointer") señala el desplazamiento (dentro del segmento de pila SS) donde se encuentra el origen de la zona ocupada por las variables dinámicas.
• Existen dos registros denominados "de índice", en razón de su utilización muy particular; el índice fuente SI ("Source index") y el índice destino DI ("Destination index"). Generalmente
estos dos registros se utilizan con alguno de los registros de uso general y con ciertas instrucciones específicamente pensadas para transferir datos (dentro de un rango de posiciones de memoria), desde un punto inicial de un segmento de datos, a otro.
Registro de estado
Existe un registro especial, el registro de estado (FLAGS), en el que 9 de los 18 bits actúan como semáforos (indicadores del estado del procesador y del resultado de determinadas operaciones). Por ejemplo, si después de una suma aritmética hay o no desbordamiento del bit más significativo.
Los nombres y situación de cada uno, dentro de la palabra de 16 bits.
Cada bits individual puede estar "activo" (1) o "inactivo" (0), y tiene un identificador que termina en F ("Flag").
|BIT |INDICADOR DE: |USO |
|CF |Acarreo (“Carry flag”) |Indicador de arrastre del bit de mayor orden que puede ocurrir en las operaciones |
| | |aritméticas suma y resta |
|PF |Paridad (“Parity flag”) |Si esta activo indica un número par de bits activos. Esta información es útil cuando el |
| | |procesador controla trasmisiones de datos |
|AF |Acareo auxiliar |Indicador de ajuste en operaciones aritméticas con cantidades BCD |
|ZF |Cero (“zero flag”) |Es activo si el resultado de la operación es cero o resultado de comparación igual |
|SF |Signo (“Sing flag”) |Si esta activo indica que el resultado de operación o de comparación son negativos |
|TF |Detención (“Trap flag”) |Si esta activo, el procesador genera automáticamente una interrupción después de la |
| | |ejecución de cada instrucción, lo q permite controlar paso a paso la ejecución del |
| | |programa. |
| | |Este bit debe estar normalmente inactivo(a 0) |
|IF |Interrupción (“Interrupt |Esta bit controla el estado del sistema de interrupciones |
| |flag”) |Enmascarables. Cuando esta activo (1) permite las interrupciones; el estado inactivo (0)|
| | |las deshabilita |
|DF |Dirección (“Direction flag”) |Indica la dirección de las operaciones |
|OF |Desbordamiento |Señala desbordamiento aritmético |
[pic]
TELEMATICA
DIEGO RODRIGUEZ
CLASES DE DIRECCIONES IP
CLASES DE DIRECCIONES IP
Una dirección IP es una dirección de 32 bits, escrita generalmente con el formato de 4 números enteros separados por puntos. Una dirección IP tiene dos partes diferenciadas:
➢ Los números de la izquierda indican la red y se les denomina netID (identificador de red).
➢ Los números de la derecha indican los equipos dentro de esta red y se les denomina host-ID (identificador de host).
Las direcciones IP fueron organizados en clases, hubo cinco clases de direcciones IP.
A continuación estas completamente explicadas.
Clase A: En una dirección IP de clase A, el primer byte representa la red.
El bit más importante (el primer bit a la izquierda) está en cero, lo que significa que hay 2 7 (00000000 a 01111111) posibilidades de red, que son 128 posibilidades. Sin embargo, la red 0
(bits con valores 00000000) no existe y el número 127 está reservado para indicar su equipo. Las redes disponibles de clase A son, por lo tanto, redes que van desde 1.0.0.0 a 126.0.0.0 (los últimos bytes son ceros que indican que se trata seguramente de una red y no de equipos).
Los tres bytes de la izquierda representan los equipos de la red. Por lo tanto, la red puede contener una cantidad de equipos igual a:
224-2 = 16.777.214 equipos.
En binario, una dirección IP de clase A luce así:
|0 |Xxxxxxx |Xxxxxxxx |Xxxxxxxx |Xxxxxxxx |
|Red |Equipos |
Clase B: En una dirección IP de clase B, los primeros dos bytes representan la red.
Los primeros dos bits son 1 y 0; esto significa que existen 214 (10 000000 00000000 a 10 111111 11111111) posibilidades de red, es decir, 16.384 redes posibles. Las redes disponibles de la clase B son, por lo tanto, redes que van de 128.0.0.0 a 191.255.0.0.
Los dos bytes de la izquierda representan los equipos de la red. La red puede entonces contener una cantidad de equipos equivalente a: Por lo tanto, la red puede contener una cantidad de equipos igual a:
216-21 = 65.534 equipos.
En binario, una dirección IP de clase B luce así:
|10 |Xxxxxx |Xxxxxxxx |Xxxxxxxx |Xxxxxxxx |
|Red |Ordenadores |
Clase C: En una dirección IP de clase C, los primeros tres bytes representan la red. Los primeros tres bits son 1,1 y 0; esto significa que hay 221 posibilidades de red, es decir, 2.097.152. Las redes disponibles de la clases C son, por lo tanto, redes que van desde 192.0.0.0 a 223.255.255.0.
El byte de la derecha representa los equipos de la red, por lo que la red puede contener:
28-21 = 254 equipos.
En binario, una dirección IP de clase C luce así:
|110 |Xxxxx |Xxxxxxxx |Xxxxxxxx |Xxxxxxxx |
|Red |Ordenadores |
Clase D y E: Las direcciones de clase D se utilizan para la multidifusión, y las direcciones de clase E no están disponibles para uso general, que están reservados para propósitos futuros.
➢ La dirección 0.0.0.0 es utilizada por las máquinas cuando están arrancando o no se les ha asignado dirección.
➢ La dirección que tiene su parte de host a cero sirve para definir la red en la que se ubica. Se denomina dirección de red.
➢ La dirección que tiene su parte de host a unos sirve para comunicar con todos los hosts de la red en la que se ubica. Se denomina dirección de broadcast.
➢ Las direcciones 127.x.x.x se reservan para pruebas de retroalimentación. Se denomina dirección de bucle local o loopback.
En la actualidad cualquier máscara de red puede ser asignados a cualquier rango de direcciones IP.
Direccionamiento IP
QUE ES UNA DIRECCIÓN IP
CLASES DE DIRECCIONES IP
SUBREDES Y MASCARAS DE SUBRED
FORMAS DE DIVISION EN SUBREDES
DIRECCIONES IP PRIVADAS
QUE ES UNA DIRECCIÓN IP
Las direcciones del nivel de red en Internet pueden representarse de manera simbólica o numérica. Una dirección simbólica es por ejemplo www. pntic.mec.es Una dirección numérica se representa por cuatro campos separados por puntos, como 193.144.238.1, los cuales no pueden superar el valor 255 (11111111 en binario). La correspondencia entre direcciones simbólicas y numéricas las realiza el DNS (Domain Name System).
Para poder identificar una máquina en Internet cada una de ellas tiene una dirección IP (Internet Protocol) la cual es asignada por InterNIC (Internet Network Information Center).
Las direcciones numéricas son las que entiende la máquina y se representan por 32 bits con 4 campos de 8 bits cada uno, aunque normalmente se pasan de binario a decimal. Por ejemplo 139.3.2.8 es en binario:
|10001011 |00000011 |00000010 |00001000 |
|\______/ |\______/ |\______/ |\______/ |
|139 |3 |2 |8 |
CLASES DE DIRECCIONES IP
Una parte de los bits representa la red y el resto la máquina (host). En este caso como veremos los dos primeros campos representan la red 139.3 (16 bits) y 2.8 (16 bits) al host. Los paquetes de datos que maneja Internet a nivel de red se llaman datagramas. Estos llevan tanto la dirección de la máquina transmisora como la receptora. Existen cinco clases de direcciones IP según la manera de repartir los bits entre la dirección de red y el número de host.
Clase A
|0 |RED |NÚMERO DE HOST |
|0 |1 |8 16 24 |
| | |31 |
Clase B
|1 |0 |RED |NÚMERO DE HOST |
|0 |1 | 8 |16 24 31 |
Clase C
|1 |1 |0 |RED |NÚMERO DE HOST |
|0 |1 | | 8 16 |24 31 |
Clase D
|1 |1 |1 |0 |DIRECCIONES MULTICAST |
|0 |1 | | | 8 16 24 31 |
Clase E
|1 |1 |1 |1 |RESERVADAS |
|0 |1 | | | 8 16 24 31 |
En las clases A, B, y C las direcciones con la parte de número de host con todos los bits puestos a ‘0’ indican la red por lo que no se pueden asignar a ningún host; igualmente tan poco se pueden asignar a un host las direcciones con el número de host con todos los bits puestos a ‘1’ porque se dejan para los paquetes broadcast dirigidos a todas las máquinas de la red. Por ejemplo en la red anterior que es clase B la red es 139.3.0.0 y la dirección broadcast 139.3.255.255.
• Las direcciones de Clase A usan 7 bits para el número de red dando un total de 126 (128-2) posibles redes de este tipo ya que la dirección 0.0.0.0 se utiliza para reconocer la dirección de red propia y la red 127 es la del lazo interno de la máquina. Los restantes 24 bits son para el número de host –quitando las que son todos los bits a 0 ó a 1 –con lo cual tenemos hasta 224-2=16.777.216-2=16.777.214 direcciones–. Son las redes 1.0.0.0 a 126.0.0.0
• Las direcciones de Clase B utilizan 14 bits para la dirección de red (16.382 posibles redes de este tipo) y 16 bits para el host (hasta 65.534 máquinas). Son las redes 128.0.0.0 a 191.255.0.0
• Las direcciones de clase C tienen 21 bits para la red (2.097.150 redes) y 8 bits para el host (254 máquinas). Son las redes 192.0.0.0 a 223.255.255.0
• Las direcciones de clase D están reservadas para multicasting que son usadas por direcciones de host en áreas limitadas.
• Las direcciones de Clase E están reservadas para uso futuro.
La clase que se elija para una red dada dependerá del número de máquinas que tenga y las que se prevean en el futuro. Como vimos antes el número de red es asignado por el NIC o por el organismo de cada país en quien él delegue. El número de host lo asignará el administrador que controla la red.
SUBREDES Y MÁSCARAS DE SUBRED
Puede darse el caso de que una red crezca en un número de máquinas significativo o que se quiera instalar una nueva red además de la que ya existía.
Para conseguir mayor funcionalidad podemos dividir nuestra red en subredes dividiendo en dos partes el número de host, una para identificar la subred, y la otra parte para identificar la máquina (subnetting). Esto lo decidirá el responsable de la red sin que intervenga el NIC. Podemos tener asignada una red –normalmente de las clases B ó C– y dividirla en dos o más subredes según nuestras necesidades comunicados por routers.
Clase B
|1 |0 |RED |SUBRED |NÚMERO DE HOST |
|0 |1 | 8 |16 | 24 31 |
Clase C
|1 |1 |0 |RED |SRED |Nº DE HOST |
|0 |1 | | 8 16 |24 | 31 |
El conjunto formado por la subred y el número de host se conoce como dirección local o parte local. Un host remoto verá la dirección local como el número de host.
El número de bits correspondientes a la subred y al número de host son elegidos libremente por el administrador. Esta división se realiza utilizando una máscara de subred. Esta es un número binario de 32 bits. Los bits que estén a "1" indicarán el campo de la dirección IP dedicada a la red y los bits puestos a "0" indicarán la parte dedicada al host. La máscara de subred se representa normalmente en notación decimal. Por ejemplo si no utilizamos subredes y dejamos la red como una sola, para una red clase B la máscara será:
|11111111 |11111111 |00000000 |00000000 |
|\______/ |\______/ |\______/ |\______/ |
|255 |255 |0 |0 |
Si queremos dividirla en subredes tomaremos los 16 bits de la parte local y pondremos a "1" la parte que queremos represente a las subredes. Por ejemplo si queremos 8 subredes necesitaremos en binario 3 bits para referenciarlas. La máscara que necesitamos será: 11111111.11111111.11100000.00000000 es decir 255.255.224.0 en decimal. Al emplear 13 bits para el host podríamos tener hasta 213-2=8190 máquinas en cada subred.
Lo normal a la hora de añadir "unos" a la máscara inicial para definir las subredes es hacerlo de manera contigua para ver los campos claramente.
Si tenemos una red clase C cuya máscara sin subredes es 255.255.255.0 y queremos dividirla en 4 subredes solo necesitamos 2 bits para definirlas:
|11111111 |11111111 |11111111 |11000000 |
|\______/ |\______/ |\______/ |\______/ |
|255 |255 |255 |192 |
Esta máscara permitiría hasta 26-2=62 hosts en cada subred.
FORMAS DE DIVISIÓN EN SUBREDES
Hay dos formas de dividir una red en subredes: longitud estática y longitud variable. Se pueden utilizar según el protocolo de encaminamiento. El encaminamiento IP nativo solo soporta
longitud estática al emplear el protocolo RIP. Con el protocolo RIP2 se consigue utilizar longitud variable.
La longitud estática implica que todas las subredes deben tener la misma máscara lo que obligará a poner la que necesite la que tenga más ordenadores. La longitud variable permite que no haya que variar las direcciones de red caso de cambios en una de sus subredes. Una subred que necesita dividirse en otras dos puede hacerlo a añadiendo un bit a su máscara sin afectar al resto. No todos los routers y host soportan la longitud variable de máscaras. Si un host no soporta este método deberá encaminarse hacia un router que si lo soporte.
Ejemplo de Subnetting estática
Supongamos que tenemos una red clase B, 140.155, y sabemos que no tendremos más de 256 subredes y no más de 254 hosts, podemos dividir la dirección local con 8 bits para las redes y otros 8 para el número de hosts con una máscara del tipo 255.255.255.0 –es decir que en binario sería 11111111.11111111.11111111.00000000–.
Si tenemos una red clase C con muchas subredes y con pocos hosts podemos poner una máscara 255.255.255.224 –recordando que 224 es 11100000 en base 2– es decir que hemos dividido la dirección local en 3 bits para redes y 5 para hosts. O sea 23=8 subredes y 25-2=30 hosts.
Las subredes serían:
00000000)2 = 0)10
00100000)2 = 32)10
01000000)2 = 64)10
01100000)2 = 96)10
10000000)2 = 128)10
10100000)2 = 160)10
11000000)2 = 192)10
11100000)2 = 224)10
Por ejemplo si nuestra red clase C es 193.144.238 y tomamos la máscara 255.255.255.224 anterior:
|SUBRED |NÚMEROS DE HOST |
| |PARA CADA SUBRED |
|193.144.238.0 |193.144.238.1 a 193.144.238.30 |
|193.144.238.32 |193.144.238.33 a 193.144.238.62 |
|193.144.238.64 |193.144.238.65 a 193.144.238.94 |
|193.144.238.96 |193.144.238.97 a 193.144.238.126 |
|193.144.238.128 |193.144.238.129 a 193.144.238.158 |
|193.144.238.160 |193.144.238.161 a 193.144.238.190 |
|193.144.238.192 |193.144.238.193 a 193.144.238.222 |
|193.144.238.224 |193.144.238.225 a 193.144.238.254 |
Direcciones Broadcast
Hay diferentes tipos de broadcast:
• Direcciones de broadcast limitadas: La dirección con todos los bits a "1" –255.255.255.255– se usa en redes que soportan broadcasting, e indica todos los host de la subred. Los routers no reenvían la información fuera de la subred.
• Direcciones de broadcast de red: En una red sin subredes poniendo a "1" los bits del campo de número de host
• Direcciones de broadcast de subred: Poniendo a "1" solo la parte del número de host de la dirección local.
• Broadcast a todas las subredes: Poniendo toda la parte local a "1".
Multicasting
Para tener más flexibilidad que la proporcionada por el método broadcast que se dirige a todos los miembros de una subred o de una red, existe el método multicast, el cual nos permite dirigirnos a grupos de hosts dentro de la red.
El datagrama IP para multicast como vimos antes es de clase D cuyos cuatro primeros bits son 1110 –el primer octeto va de 11100000 a 11101111– luego el rango de direcciones será de 224.0.0.0 a 239.255.255.255.
Existen dos tipos de grupos:
Grupos permanentes: Son los que han sido estandarizados. Los hosts asignados a estos grupos no son permanentes, pueden afiliarse a él o ser quitados de él.
Grupos importantes de este tipo son:
224.0.0.0 Dirección reservada de base
224.0.0.1 Todos los sistemas de la subred
224.0.0.2 Todos los routers de la subred
224.0.0.1 Todos los routers OSPF
224.0.0.1 Todos los routers OSPF designados
Grupos transitorios: Son los grupos que no son permanentes y se van creando según las necesidades.
DIRECCIONES IP PRIVADAS
Las redes privadas de organizaciones que no están directamente conectadas a Internet –esto es, las redes que se conectan por medio de un proxy o un router a una única línea con una sola dirección IP dada por un proveedor de servicios– tienen asignado unos rangos de direcciones IP para su funcionamiento interno. Estos son:
Para clase A una única dirección de red: 10
Para clase B 16 redes del rango 172.16 a 172.31
Para clase C 256 direcciones de red: 192.168.0 a 192.168.255
Estas direcciones IP no son utilizadas por los routers para su comunicación con Internet, y se utilizan solo dentro de la organización. Estas redes (Intranet) tienen la ventaja de ser mucho menos accesibles a ataques desde el exterior.
REDES
Las redes constan de dos o más computadoras conectadas entre sí y permiten compartir recursos e información. La información por compartir suele consistir en archivos y datos. Los recursos son los dispositivos o las áreas de almacenamiento de datos de una computadora, compartida por otra computadora mediante la red. La más simple de las redes conecta dos computadoras, permitiéndoles compartir archivos e impresos.
Una red mucho más compleja conecta todas las computadoras de una empresao compañía en el mundo. Para compartir impresoras basta con un conmutador, pero si se desea compartir eficientemente archivos y ejecutar aplicaciones de red, hace falta tarjetas de interfaz de red (NIC, NetWare Interfaces Cards) y cables para conectar los sistemas. Aunque se puede utilizar diversos sistemas de interconexión vía los puertos series y paralelos, estos sistemas baratos no ofrecen la velocidad e integridad que necesita un sistema operativo de red seguro y con altas prestaciones que permita manejar muchos usuarios y recursos
Redes de Área Local (LAN)
La red local o LAN (Local Area Network) es un sistema de comunicaciones de alta velocidad que conecta microcomputadoras o PC y/o periféricos que se encuentran cercanos, por lo general dentro del mismo edificio. Una LAN consta de hardware y software de red y sirve para conectar las que están aisladas. Una LAN da la posibilidad de que los PC compartan entre ellos programas, información y recursos, como unidades de disco, directorios e impresoras y de esta manera esta a disposición la información de cada puesto de trabajo los recursos existentes en otras computadoras.
Características de las LAN's: El radio que abarca es de pocos kilómetros, Por ejemplo: edificios, un campus universitario, un complejo industrial, etc. Utilizan un medio privado de comunicación. La velocidad de transmisión es de varios millones de bps. Las velocidades más habituales van desde 1 hasta 16 Mbits, aunque se está elaborando un estándar para una red que alcanzará los 100 Mbps. Pueden atender a cientos de dispositivos muy distintos entre sí (impresoras, ordenadores, discos, teléfonos, módems, etc.).
Red de Área Amplia (WAN)
Es un sistema de comunicación de alta velocidad que conecta PC's, entre sí para intercambiar información, similar a la LAN; aunque estos no están limitados geográficamente en tamaño. La WAN suele necesitar un hardware especial, así como líneas telefónicas proporcionadas por una compañía telefónica.
Topología de redes.
Se llama topología de una Red al patrón de conexión entre sus nodos, es decir, a la forma en que están interconectados los distintos nodos que la forman. Los Criterios a la hora de elegir una topología, en general, buscan que eviten el coste del encaminamiento (necesidad de elegir los caminos más simples entre el nodo y los demás), dejando en segundo plano factores como la renta mínima, el coste mínimo, etc. Otro criterio determinante es la tolerancia a fallos o facilidad de localización de éstos. También tenemos que tener en cuenta la facilidad de instalación y reconfiguración de la Red.
* Topología en bus
Una Red en forma de Bus o Canal de difusión es un camino de comunicación bidireccional con puntos de terminación bien definidos. Cuando una estación trasmite, la señal se propaga a ambos lados del emisor hacia todas las estaciones conectadas al Bus hasta llegar a las terminaciones del mismo. Así, cuando una estación trasmite su mensaje alcanza a todas las estaciones, por esto el Bus recibe el nombre de canal de difusión.
* Topología en anillo
Esta se caracteriza por un camino unidireccional cerrado que conecta todos los nodos. Dependiendo del control de acceso al medio, se dan nombres distintos a esta topología: Bucle; se utiliza para designar aquellos anillos en los que el control de acceso está centralizado (una de las estaciones se encarga de controlar el acceso a la red). Anillo; se utiliza cuando el control
de acceso está distribuido por toda la red. Como las características de uno y otro tipo de la red son prácticamente las mismas, se utiliza el término anillo para las dos.
* Topología estrella
La topología en estrella se caracteriza por tener todos sus nodos conectados a un controlador central. Todas las transacciones pasan a través del nodo central, siendo éste el encargado de gestionar y controlar todas las comunicaciones. Por este motivo, el fallo de un nodo en particular es fácil de detectar y no daña el resto de la red, pero un fallo en el nodo central desactiva la red completa.
Tarjeta de Interfaz de Red
Para comunicarse con el resto de la red, cada computadora debe tener instalada una tarjeta de interfaz de red (Network Interface Card, NIC). Se les llama también adaptadores de red o sólo tarjetas de red. En la mayoría de los casos, la tarjeta se adapta en la ranura de expansión de la computadora, aunque algunas son unidades externas que se conectan a ésta a través de un puerto serial o paralelo. Las tarjetas internas casi siempre se utilizan para las PC's, PS/2 y estaciones de trabajo como las SUN's. Las tarjetas de interfaz también pueden utilizarse en mini computadoras y mainframes. A menudo se usan cajas externas para Mac's y para algunas computadoras portátiles.
Son ocho las funciones de la NIC:
1.
2. Comunicaciones de host a tarjeta
3. Buffering
4. Formación de paquetes
5. Conversión serial a paralelo
6. Codificación y decodificación
7. Acceso al cable
8. Saludo
9. Transmisión y recepción.
10. Categorías del cable UTP:
11. Cada categoría especifica unas características eléctricas para el cable: atenuación, capacidad de la línea e impedancia. Existen actualmente 8 categorías dentro del cable UTP:
12.
13. Categoría 1: Este tipo de cable esta especialmente diseñado para redes telefónicas, es el típico cable empleado para teléfonos por las compañías telefónicas. Alcanzan como máximo velocidades de hasta 4 Mbps.
14. Categoría 2: De características idénticas al cable de categoría 1.
15. Categoría 3:Es utilizado en redes de ordenadores de hasta 16 Mbps. de velocidad y con un ancho de banda de hasta 16 Mhz.
16. Categoría 4: Esta definido para redes de ordenadores tipo anillo como Token Ring con un ancho de banda de hasta 20 Mhz y con una velocidad de 20 Mbps.
17. Categoría 5: Es un estándar dentro de las comunicaciones en redes LAN. Es capaz de soportar comunicaciones de hasta 100 Mbps. con un ancho de banda de hasta 100 Mhz. Este tipo de cable es de 8 hilos, es decir cuatro pares trenzados. La atenuación del cable de esta categoría viene dado por esta tabla referida a una distancia estándar de 100 metros:
18.
19. Categoría 5e: Es una categoría 5 mejorada. Minimiza la atenuación y las interferencias. Esta categoría no tiene estandarizadas las normas aunque si esta diferenciada por los diferentes organismos.
20. Categoría 6: No esta estandarizada aunque ya se está utilizando. Se definirán sus características para un ancho de banda de 250 Mhz.
21. Categoría 7:No esta definida y mucho menos estandarizada. Se definirá para un ancho de banda de 600 Mhz. El gran inconveniente de esta categoría es el tipo de conector seleccionado que es un RJ-45 de 1 pines.
22. En esta tabla podemos ver para las diferentes categorías, teniendo en cuenta su ancho de banda, cual sería las distancias máximas recomendadas sin sufrir atenuaciones que hagan variar la señal:
Los tipos de fibra óptica son:
* Fibra multimodal
En este tipo de fibra viajan varios rayos ópticos reflejándose a diferentes ángulos, los diferentes rayos ópticos recorren diferentes distancias y se desfasan al viajar dentro de la fibra. Por esta razón, la distancia a la que se puede trasmitir está limitada.
* Fibra multimodal con índice graduado
En este tipo de fibra óptica el núcleo está hecho de varias capas concéntricas de material óptico con diferentes índices de refracción. En estas fibras el número de rayos ópticos diferentes que viajan es menor y, por lo tanto, sufren menos el severo problema de las multimodales.
* Fibra monomodal:
Esta fibra óptica es la de menor diámetro y solamente permite viajar al rayo óptico central. No sufre del efecto de las otras dos pero es más difícil de construir y manipular. Es también más costosa pero permite distancias de transmisión mayores.
Transmisión
Trasladar información de un lugar a otro
Esta información puede ser:
* Voz
* Datos
* Imágen
* Vídeo
* Banda base es la señal de una sola transmisión en un canal, banda ancha significa que lleva más de una señal y cada una de ellas se transmite en diferentes canales, hasta su número máximo de canal.
* En los sistemas de transmisión, la banda base es generalmente utilizada para modular una portadora. Durante el proceso de demodulación se reconstruye la señal banda base original. Por ello, podemos decir que la banda base describe el estado de la señal antes de la modulación y de la multiplexación y después de la demultiplexación y desmodulación.
* Por ejemplo, es señal de banda base la obtenida de la salida de video compuesto de dispositivos como grabadores/reproductores de video y consolas de juego, a diferencia de las señales de televisión que deben ser moduladas para poder transportarlas vía aérea (por señal libre o satélite) o por cable.
Red de área metropolitana (MAN): una red que conecta las redes de un área (dos o más redes locales juntas) pero que no se extiende más allá de los límites de la ciudad inmediata, o del área metropolitana. Los enrutadores (routers) múltiples, los interruptores (switch) y los cubos están conectados para crear una MAN.
La arquitectura SNA
Es un modelo que presenta similitudes con el modelo de referencia OSI. Se compone de las siguientes capas:
Física: SNA no define protocolos específicos para su capa de control física. Se puede emplear cualquier otro estándar para su implementación.
Control de Enlace de Datos -Data link control (DLC)-: Define varios protocolos incluidos el SDLC (Synchronous Data Link Control) y el protocolo de comunicación Token Ring Network para LAN entre iguales (peers).
Control de ruta -Path control-: Implementa mucha de las funciones de la capa de red OSI.
Control de transmisión –Transmission control-: Proporciona un servicio de conexión de punta a punta confiable, así como servicios de cifrado y descifrado.
Control de Flujo de Datos –Data flow control-: Administra el procesamiento de las peticiones y respuestas, asigna el turno para la comunicación, y puede interrumpir el flujo de información pedida.
Servicios de Presentación-Presentation services-: Especifica los algoritmos de transformación de datos para cambiarlos de una forma a otra, sincroniza las transacciones y coordina los recursos compartidos.
Servicios de Transacción-Transaction services-: Proporciona servicios de aplicación en forma de programas que implementan el procesamiento distribuido o servicios de gestión.
Interfaz
Lo que permite que dos entidades distintas se comuniquen. Por ejemplo entre un un frances y un español el interfaz seria el correspondiente diccionario bilingue. Entre dos equipos, A yB cada uno con una salida para transmitir y una entrada para recibir, el interfaz seria el cable cruzado que conectase transmisor A con receptor B y transmisor B con receptor A.
Protocolo
Conjunto de reglas de comunicación que dos entidades conocen y respetan para realizar conjuntamente la función que tienen asignada. Un protocolo es por tanto un lenguaje, con su sintaxis, su semántica y su adecuada temporización. La sintaxis entronca con el como, la semántica con el qué (el significado), y la temporización con el cuando. Los hay monolíticos y estructurados.
Protocolos monolíticos
Se intenta resolver el problema de la comunicación de una sola vez.
Protocolos estructurados
El protocolo divide el problema de la comunicación en varias partes que se resuelven con protocolos distintos e independientes.
Arquitectura de protocolos
La funcionalidad de un sistema de telecomunicaciones se divide en subsistemas jerárquicos. Cuando tenemos un subsistema debemos tener también los subsitemas inferiores. Una arquitectura de protocolos es una técnica para estructurar jerarquicamentre la funcionalidad de un sistema de comunicaciones, utilizando protocolos estructurados y definiendo su estructura.
Servicio
Conjunto de funciones que realiza un nivel de la jerarquía de la arquitectura de protocolos y todos los inferiores, para ofrecer una funcionalidad al nivel inmediatamente superior que se considera usuario del anterior.
Entidades gemelas:
Son entidades que se entienden. Siempre que en una arquitectura de protocolos tenemos una entidad de un tipo, la entidad con la que está dialogando tiene que ser igual, nivel por nivel.
PDU:
Los datos que se intercambian entidades gemelas.
Planos de arquitecturas de protocolos:
Representan los distintos flujos de información a traves de las redes de telecomunicaciones. Se dividen en tres pero, ojo, no simpre se respeta estrictamente esta división.
Plano de usuario: Información que fluye desde la aplicación hasta el nivel físico (cables, aire…). Por el fluyen los datos del usuario.
Plano de señalización y control: Información para la utilización de los servicios de la red, entre organos de la red. Se conoce como información de señalización. La genera y la destruye la propia red.
Plano de gestión: Información necesaria para la operación y administración de los servicios. Por ejemplo la información de tarificación, o, si se produce algún error, lo que se comunica a los administradores de la red para que pongan una solución.
TOPOLOGIAS.- Es una estructura que consta de caminos y que proporciona el medio de interconexión entre los nodos de la red. Existen varios tipos de topologías entre las cuales hay:
BUS Se caracteriza por el uso de un medio multipunto.
Todas las estaciones se encuentran directamente conectadas, a través de interfaces físicas llamdas tomas de conexión , a un medio de transmisión. A través del funciomiento del FULL DUPLEX, entre la estación y la toma de conexión permite la transmisión de datos a través del bus y la recepción de estos desde aquél. La transmisión se propaga a través del medio en ambos sentidos y es recibida por el resto de estaciones. En cada extremo existe un terminador que absorbe la señal eliminándola del bus.
ARBOL Es una generalización de la topología en bus. El medio de transmision es un cable ranmificado sin bucles cerrados. Comienza en un punto llamado.
RAIZ. Los cables comienzan en mencionado punto y cada uno presentan ranmificaciones. La transmisión se propaga a través del medio y alcanza al resto de estaciones.
ANILLO.-Consta de un conjunto de repetidores unidos por enlaces punto a punto formando un bucle cerrado. El repetidor es un dispositivo capaz de recibir datos a través del enlace y de
transmitrilos bit a bit, a través de otro enlaceLos enlaces son unidireccionales, los datos se transmiten en un solo sentido, de modo que estos circulan alrededor del anilloCada estación se conecta a la red mediante un repetidor, transmitiendo los datos hacia la red a través de el.
ESTRELLA.- Cada estación está directamente conectada a un nodo central generalmente a dos enlaces de punto a punto, uno para transmisión y otro para recepción.El modo de funcionamiento es de difusión; es decir cuando se transmite una trama de información por parte de una estación se retransmite sobre todos los enlaces de salida del nodo central. Solo se puede transmitir una estación en un tiempo determinado.También el nodo central funciona como dispositivo de conmutación de tramas
Control de acceso al medio (MAC)
El MAC es el mecanismo encargado del control de acceso de cada estación al medio. El MAC puede realizarse de forma distribuida cuando todas las estaciones cooperan para determinar cuál es y cuándo debe acceder a la red. También se puede realizar de forma centralizada utilizando un controlador.
Control de enlace lógico (LLC)
Esta capa es la encargada de transmitir tramas entre dos estaciones sin tener que pasar por ningún nodo intermedio. Esta capa debe permitir el acceso múltiple. Esta capa debe identificar todos los posibles accesos a ella, ya sean de una capa superior como estaciones destino u otros.
- Servicios LLC: el LLC debe controlar el intercambio de datos entre dos usuarios, y para ello puede establecer una conexión permanente, una conexión cuando se requiera el intercambio de datos o una mezcla de ambas (sólo se establece conexión permanente cuando sea necesaria).
- Protocolo LLC: hay varias formas de utilización de este protocolo que van desde envíos de tramas con requerimiento de trama de confirmación hasta conexiones lógicas entre dos estaciones previo intercambio de tramas de petición de conexión.
Las LAN's pueden ser estáticas y dinámicas.
Las redes de difusión se pueden dividir también en estáticas y dinámicas dependiendo de como se asigna el canal. Una asignación estática típicamente divide el tiempo en intervalos discretos y ejecuta un algoritmo de asignación cíclica. Permitiendo a cada máquina transmitir únicamente cuando le llega su turno. La asignación estática desperdicia la capacidad del canal cuando una máquina no tiene que decir durante su segmento asignado.
Los métodos de asignación dinámica para un canal común son centralizados o descentralizados. En el método de asignación de canal centralizado hay una sola entidad. Se podría hacer esto aceptando peticiones y tomando una decisión de acuerdo a un algoritmo interno.
El método de asignación de canal descentralizado en este no hay una entidad central. Cada máquina debe decidir por sí misma si transmite o no.
TOPOLOGIA EN BUS Y ARBOL
MEDIO MULTIPUNTO
LA TRANSMISION SE PROPAGA A TRAVES
TODAS LAS ESTACIONES ESCUCHAN
NECESIDAD DE IDENTIFICAR LAS ESTACIONES DESTINO
CADA ESTACION TIENE UNA DIRECCION
CONEXIÓN FULL DUPLEX ENTRE LA ESTACION Y LA TOMA DE CONEXIÓN
NECESIDAD DE REGULAR LA TRANSMISION PARA EVITAR COLISIONES
TERMINADOR ABSORBE LAS TRAMAS AL FINAL DEL MEDIO
LAN EN BUS
BALANCEO DE LA SEÑAL
LA SEÑAL DEBE SER LO SUFICIENTE FUERTE PARA CUMPLIR LOS REQUISITOS DE LOS RECEPTORES EN CUALQUIER COMBINACION DE TRANSMISION
RELACION SEÑAL RUIDO ADECUADA
NO TAN FUERTE QUE SOBRECARGUE EL TRANSMISOR
USUALMENTE SE DIVIDE LA RED EN PEQUEÑOS SEGMENTOS
LOS ENLACES SE IMPLEMENTAN CON AMPLIFICADORES O REPETIDORES
MEDIOS DE TRANSMISION EN BUS
PAR TRENZADO
NO ES PRACTICO EN BUS COMPARTIDO CON ALTAS VELOCIDADES DE TRANSMISION
CABLE COAXIAL DE BANDA BASE
USADO EN ETHERNET
TOPOLOGIA EN ANILLO
REPETIDORES UNIDOS POR ENLACES PUNTO A PUNTO EN UN LAZO CERRADO
RECIBEN DATOS DE UN ENLACE Y LO RETRANSMITEN
ENLACES SON UNIDIRECCIONALES
LAS ESTACIONES ESTÁN UNIDAS A LOS REPETIDORES
DATOS DE LAS TRAMAS
PASAN POR TODAS LAS ESTACIONES
LA ESTACION DESTINO RECONOCE LA TRAMA Y LA COPIA
LA TRAMA CIRCULA DE VUELTA AL ORIGEN DONDE ES ELIMINADA
MAC DETERMINA CUANDO UNA ESTACION PUEDE INSERTAR UNA TRAMA
LAN EN ANILLO
CADA REPETIDOR SE CONECTA AL SIGUIENTE MEDIANTE UN ENLACE UNIDIRECCIONAL
CAMINO CERRADO UNICO
LOS DATOS SON TRANSFERIDOS BIT A BIT DESDE UN REPETIDOR AL SIGUIENTE
EL REPETIDOR REGENERA Y REPITE CADA BIT
REPETIDORES REALIZAN INSERCION DE DATOS, RECEPCION Y E LIMINACION
LOS REPETIDORES ACTUAN COMO PUNTO DE CONEXIÓN DEL DISPOSITIVO
LOS PAQUETES SON ELIMINADOS POR EL REPETIDOR DESTINO O POR EL QUE LO ENVIO
MEDIO EN EL ANILLO
PAR TRENZADO, COAXIAL BANDA BASE, FIBRA OPTICA, NO USA CABLE COAXIAL BANDA ANCHA
LAN EN ESTRELLA BUS LOGICO
USO DE PAR TRENZADO NO APANTALLADO(TELEFONO)
COSTE DE INSTALACION MINIMO
UNIDOS A UN HUB CENTRAL
DOS ENLACES: TRANSMITIR Y RECIBIR
HUB REPITE LA SEÑAL QUE LLEGA A TODOS LOS ENLACES
LONGITUDES DE LOS ENLACES DE 100M
BUS LOGICO: CON COLISION
TOPOLOGIA EN ESTRELLA
CADA ESTACION SE CONECTA DIRECTAMENTE A UN NODO CENTRAL(NORMALMENTE POR PUNTO A PUNTO)
EL NODO CENTRAL PUEDE HACER DIFUSION(ESTRELLA FISICA, BUS LOGICO)(SOLO UNA ESTACION PUEDE TRANSMITIR A UN TIEMPO)
EL NODO CENTRAL PUEDE ACTUAR COMO CONMUTADOR DE TRAMAS
La conmutación de paquetes es el envio de datos en una red de computadoras. Un paquete es un grupo de información que consta de dos partes: los datos propiamente dichos y la información de control, en la que está especificado la ruta a seguir a lo largo de la red hasta el destino del paquete. Mil octetos es el límite de longitud superior de los paquetes, y si la longitud es mayor el mensaje se fragmenta en otros paquetes.
. Un circuito de conmutación estará compuesto por una serie de contactos que representarán las variables lógicas de entrada y una o varias cargas que representarán las variables lógicas o funciones de salida. Los contactos pueden ser normalmente abiertos (NA) o normalmente cerrados (NC). Los primeros permanecerán abiertos mientras no se actúe sobre ellos (por ejemplo al pulsar sobre interruptor, saturar un transistor, etc.). Los contactos NC funcionarán justamente al contrario. Esto significa que si se actúa sobre un contacto NA se cerrará y si se hace sobre uno NC se abrirá.
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
(TICS)
La Tecnologías de la Información y Comunicación han permitido llevar la globalidad al mundo de la comunicación, facilitando la interconexión entre las personas e instituciones a nivel mundial, y eliminando barreras espaciales y temporales
Se denominan Tecnologías de la Información y las Comunicación al conjunto de tecnologías que permiten la adquisición, producción, almacenamiento, tratamiento, comunicación, registro y presentación de informaciones, en forma de voz, imágenes y datos contenidos en señales de naturaleza acústica, óptica o electromagnética. Las TICS incluyen la electrónica como tecnología base que soporta el desarrollo de las telecomunicaciones, la informática y el audiovisual.
Características:
* Inmaterialidad (Posibilidad de digitalización). Las TICs convierten la información, tradicionalmente sujeta a un medio físico, en inmaterial. Mediante la digitalización es posible almacenar grandes cantidades de información, en dispositivos físicos de pequeño tamaño (discos, CD, memorias USB, etc.). A su vez los usuarios pueden acceder a información ubicada en dispositivos electrónicos lejanos, que se transmite utilizando las redes de comunicación, de una forma transparente e inmaterial.
Esta característica, ha venido a definir lo que se ha denominado como "realidad virtual", esto es, realidad no real. Mediante el uso de las TICs se están creando grupos de personas que interactúan según sus propios intereses, conformando comunidades o grupos virtuales.
* Instantaneidad. Podemos transmitir la información instantáneamente a lugares muy alejados físicamente, mediante las denominadas "autopistas de la información".
* Aplicaciones Multimedia. Las aplicaciones o programas multimedia han sido desarrollados como una interfaz amigable y sencilla de comunicación, para facilitar el acceso a las TICs de todos los usuarios. Una de las características más importantes de estos entornos es "La interactividad". Es posiblemente la característica más significativa. A diferencia de las tecnologías más clásicas (TV, radio) que permiten una interacción unidireccional, de un emisor a una masa de espectadores pasivos, el uso del ordenador interconectado mediante las redes digitales de comunicación, proporciona una comunicación bidireccional (sincrónica y asincrónica), persona- persona y persona- grupo. Se está produciendo, por tanto, un cambio hacia la comunicación entre personas y grupos que interactúan según sus intereses, conformando lo que se denomina "comunidades virtuales". El usuario de las TICs es por tanto, un sujeto activo, que envía sus propios mensajes y, lo más importante, toma las decisiones sobre el proceso a seguir: secuencia, ritmo, código, etc.
MODOS DE EXPLOTACIÓN DE LOS SISTEMAS INFORMATICOS
Proceso por Lotes
Proceso por Lotes Remotos
Proceso Interactivo en Tiempo Real
Proceso Interactivo en Tiempo Diferido
Tiempo Compartido
* Proceso por lotes: Cuando los trabajos se preparan antes de procesar y luego se ingresan ordenadamente (por lotes) al ordenador, que los procesa con la prioridad que se le indique.
* Proceso por lotes remoto: Cuando sufre un procedimiento idéntico al proceso por lotes, pero con la variante que los datos son enviados usando redes de telecomunicaciones al ordenador que se encargará de procesarlos.
* Tiempo compartido: Cuando el ordenador y sus periféricos son compartidos simultáneamente, por varios usuarios remotos, que efectúan trabajos diferentes entre sí, pero con apariencia de simultaneidad.
* Un ordenador actúa en diálogo con sus equipos terminales en tiempo real, cuando devuelve los resultados con suficiente rapidez como para afectar el funcionamiento o interactuar con el medio que los produjo en tiempo diferido.
MODOS DE EXPLOTACIÓN DE LOS SISTEMAS TELEINFORMATICOS
Fuera de Línea (off-line)
En Línea (on-line)
Interactivo
No Interactivo
* Fuera de línea (off-line): Cuando los datos que serán usados por el ordenador, se reciben en una terminal local, siendo grabados primero en tarjetas perforadas, medios magnéticos u otros equipos intermedios, para ser posteriormente ingresados al ordenador. Si se trata de la salida de datos con destino a un usuario remoto, el proceso sería análogo. Los datos que se han procesado en un ordenador se colocan en un soporte intermedio y a través de un terminal periférico son enviados al terminal distante.
* En línea (on-line): Cuando los datos de entrada pasan desde su lugar de origen a donde se utilizan en forma directa y, viceversa los datos procesados se envían desde el ordenador al usuario directamente. Este proceso evita las etapas intermedias de perforación o grabación, para su posterior procesamiento. Su uso es necesario en aquellas aplicaciones donde se necesita una rápida reacción por parte del sistema informático.
* Interactivo: Cuando los datos enviados solicitan y reciben datos de respuesta.
* No interactivo: Cuando los datos enviados no son procesados en forma directa con el objeto de dar una respuesta inmediata. Sin embargo, sí se puede confirmar la correcta recepción de ellos.
SEÑAL DIGITAL
Una señal es digital cuando sus valores se representan con variables discretas en vez de continuas. En el caso de la informática se utilizan ceros y unos (sistema binario).Por ejemplo, las computadoras utilizan dos niveles de tensión eléctrica distintos representando el cero o el uno, permitiendo así aplicar lógica y aritmética binaria.
Información digital y transmisión de señal digital
Para obtener la secuencia que compone la señal digital a partir de los datos digitales se efectúa un proceso denominado codificación. Existen multitud de métodos de codificación, mencionaremos seguidamente los más usuales.
NRZ (No Return to Zero): Es el método que empleamos para representar la evolución de una señal digital en un cronograma. Cada nivel lógico 0 y 1 toma un valor distinto de tensión.
NRZI (No Return to Zero Inverted): La señal no cambia si se transmite un uno, y se invierte si se transmite un cero.
RZ (Return to Zero): Si el bit es uno, la primera mitad de la celda estará a uno. La señal vale cero en cualquier otro caso.
Manchester: Los valores lógicos no se representan como niveles de la señal, sino como transiciones en mitad de la celda de bit. Un flanco de bajada representa un cero y un flanco de subida un uno.
Manchester diferencial: Manteniendo las transiciones realizadas en el método Manchester, en este método introduce la codificación diferencial. Al comienzo del intervalo de bit, la señal se invierte si se transmite un cero, y no cambia si se transmite un uno.
SEÑAL ANALÓGICA
Una señal analógica es un voltaje o corriente que varía suave y continuamente. Una onda senoidal es una señal analógica de una sola frecuencia. Los voltajes de la voz y del video son señales analógicas que varían de acuerdo con el sonido o variaciones de la luz que corresponden a la información que se está transmitiendo.
Información digital y transmisión de señal analógica
Al proceso por el cual obtenemos una señal analógica a partir de unos datos digitales se le denomina modulación. Esta señal la transmitimos y el receptor debe realizar el proceso contrario, denominado demodulación para recuperar la información. El módem es el encargado de realizar dicho proceso. Algunos esquemas simples de modulación son:
FSK (Modulación por desplazamiento de la frecuencia): Se modifica la frecuencia de la portadora según el valor de bit a transmitir.
ASK (modulación por desplazamiento de la amplitud): En esta técnica no se modifica la frecuencia de la portadora sino su amplitud. Los dos valores binarios se representan mediante diferentes niveles de amplitud de esta señal.
PSK (Modulación por desplazamiento de fase): La frecuencia y la amplitud se mantiene constantes y se varía la fase de la portadora para representar los niveles uno y cero con distintos ángulos de fase.
TIPOS Y MODOS DE TRANMISIÓN
Transmisión Asíncrona:
Es aquella que se transmite o se recibe un carácter, bit por bit añadiéndole bits de inicio, y bits que indican el término de un paquete de datos, para separar así los paquetes que se van enviando/recibiendo para sincronizar el receptor con el transmisor. El bit de inicio le indica al dispositivo receptor que sigue un carácter de datos; similarmente el bit de término indica que el caracter o paquete ha sido completado.
Transmisión Síncrona:
Este tipo de transmisión el envío de un grupo de caracteres en un flujo continúo de bits. Para lograr la sincronización de ambos dispositivos (receptor y transmisor) ambos dispositivos proveen una señal de reloj que se usa para establecer la velocidad de transmisión de datos y para habilitar los dispositivos conectados a los módems para identificar los caracteres apropiados mientras estos son transmitidos o recibidos. Antes de iniciar la comunicación
ambos dispositivos deben de establecer una sincronización entre ellos. Para esto, antes de enviar los datos se envían un grupo de caracteres especiales de sincronía. Una vez que se logra la sincronía, se pueden empezar a transmitir datos. Se llama sincronización al proceso mediante el que un emisor informa a un dispositivo receptor sobre los instantes en que van a transmitirse las correspondientes señales.
Sincronización por bit: Debe reconocerse el comienzo y el fin de cada bit.
Sincronización por carácter: Debe reconocerse el comienzo y el final de cada unidad de información, como puede ser un carácter o una palabra transmitida.
MODOS DE TRANSMISION
Una transmisión dada en un canal de comunicaciones entre dos equipos puede ocurrir de diferentes maneras. La transmisión está caracterizada por: la dirección de los intercambios, el modo de transmisión, el número de bits enviados simultáneamente, la sincronización entre el transmisor y el receptor
Conexiones simples, semidúplex y dúplex totales
* Una conexión simple, es una conexión en la que los datos fluyen en una sola dirección, desde el transmisor hacia el receptor. Este tipo de conexión es útil si los datos no necesitan fluir en ambas direcciones (por ejemplo: desde el equipo hacia la impresora o desde el ratón hacia el equipo.).
* Una conexión semidúplex (a veces denominada una conexión alternativa o semi-dúplex) es una conexión en la que los datos fluyen en una u otra dirección, pero no las dos al mismo tiempo. Con este tipo de conexión, cada extremo de la conexión transmite uno después del otro. Este tipo de conexión hace posible tener una comunicación bidireccional utilizando toda la capacidad de la línea.
* Una conexión dúplex total es una conexión en la que los datos fluyen simultáneamente en ambas direcciones. Así, cada extremo de la conexión puede transmitir y recibir al mismo tiempo; esto significa que el ancho de banda se divide en dos para cada dirección de la transmisión de datos si es que se está utilizando el mismo medio de transmisión para ambas direcciones de la transmisión.
Transmisión en Serie y Paralela
El modo de transmisión se refiere al número de unidades de información (bits) elementales que se pueden traducir simultáneamente a través de los canales de comunicación. De hecho, los procesadores (y por lo tanto, los equipos en general) nunca procesan (en el caso de los procesadores actuales) un solo bit al mismo tiempo. Generalmente son capaces de procesar
varios (la mayoría de las veces 8 bits: un byte) y por este motivo, las conexiones básicas en un equipo son conexiones paralelas.
Conexión Paralela
Las conexiones paralelas consisten en transmisiones simultáneas de N cantidad de bits. Estos bits se envían simultáneamente a través de diferentes canales N (un canal puede ser, por ejemplo, un alambre, un cable o cualquier otro medio físico). La conexión paralela en equipos del tipo PC generalmente requiere 10 alambres.
Conexión en Serie
En una conexión en serie, los datos se transmiten de a un bit por vez a través del canal de transmisión. Sin embargo, ya que muchos procesadores procesan los datos en paralelo, el transmisor necesita transformar los datos paralelos entrantes en datos seriales y el receptor necesita hacer lo contrario.
Banda Base: el término banda base se refiere a la banda de frecuencias producida por un transductor , tal como un micrófono , un manipulador telegráfico u otro dispositivo generador de señales, antes de sufrir modulación alguna.
Banda base es la señal de una sola transmisión en un canal, banda ancha significa que lleva más de una señal y cada una de ellas se transmite en diferentes canales, hasta su número máximo de canal.
Banda Ancha: transmisión de datos en el cual se envían simultáneamente varias piezas de información, con el objeto de incrementar la velocidad de transmisión efectiva. En ingeniería de redes este término se utiliza también para los métodos en donde dos o más señales comparten un medio de transmisión.
Multiplexión: Las comunicaciones pueden utilizar distintos canales físicos simultáneamente; es decir multiplexar para tener acceso múltiple. Tales canales pueden distinguirse uno de otro por estar separados en: tiempo (multiplexación por división de tiempo o TDM), frecuencia de portadora (multiplexación por división de frecuencia, FDM o multiplexación por división de longitud de onda, WDM), o por código (multiplexación por división de código, CDMA). Cada canal que toma parte en la multiplexación es por definición de banda estrecha (pues no está utilizando todo el ancho de banda del medio).
Modulación: proceso mediante el cual se utiliza la señal de banda base para modificar algún parámetro de una señal portadora de mayor frecuencia.
Ancho de Banda: es la cantidad de información o de datos que se puede enviar a través de una conexión de red en un período de tiempo dado. El ancho de banda se indica generalmente en bits por segundo (bps), kilobits por segundo (kbps), o megabits por segundo (mbps).
INTRODUCCION
A lo largo de la historia, el hombre ha necesitado continuamente transmitir y tratar información, por ello no ha parado de crear maquinas y métodos para procesar. Con este fin, surge la informática como una ciencia encargada del estudio y desarrollo de estas maquinas y métodos.
La informática nace de la idea de ayudar al hombre en los trabajos rutinarios y repetitivos, generalmente de calculo y gestión.
Una de las definiciones mas comúnmente aceptadas en la actualidad es la siguiente : INFORMATICA es la ciencia que estudia el tratamiento automático y racional de la información. Entre las principales funciones de la informática destacan las siguientes:
El desarrollo de nuevas máquinas (Hardware)
El desarrollo de nuevos métodos de trabajo
La construcción de aplicaciones informáticas (software)
Mejorar los métodos y aplicaciones existentes
El término se creó en Francia en 1962, y procede de la contracción de las palabras: Información automática. En los países de habla hispana se reconoció aproximadamente en 1968.
Desde el punto de vista informático, el elemento físico utilizado para el tratamiento de los datos y obtención de la información es la computadora.
Computadora (ordenador) es una máquina compuesta de elementos físicos de tipo electrónico, capaz de realizar una gran variedad de trabajos a gran velocidad y con gran precisión siempre que se le den las instrucciones adecuadas.
El conjunto de órdenes que se dan a una computadora para realizar un proceso determinado se denomina programa. Al conjunto de uno o varios programas que realizan un determinado trabajo completo se le denomina aplicación informática.
El término sistema informático se utiliza para nombrar al conjunto de elementos necesarios para la realización de aplicaciones.
La información es el elemento a tratar, y se define como todo aquello que permite adquirir cualquier tipo de conocimiento; por tanto, existirá información cuando se da a conocer algo que se desconoce.
Los datos, una vez procesados (ordenados, sumados, clasificados,...), constituyen información útil.
Para que una información sea tratada es necesario transmitirla, y para que exista transmisión de información son necesarios tres elementos:
5. El emisor que da origen a la información
6. El medio que permita la transmisión
7. El receptor que recibe la información
El conjunto de operaciones que se realizan sobre una cierta información se denomina tratamiento de la información.
Se denomina algoritmo o proceso al conjunto de operaciones necesarias para transformar los datos iniciales en los resultados que se desean obtener en determinado trabajo.
El algoritmo de resolución de un problema, se determina en su fase de análisis, previa a la automatización.
La informática se sustenta sobre tres pilares básicos:
El elemento físico (hardware)
El elemento lógico (software)
El elemento humano
Actualmente se utiliza el término firmware para denominar cierta parte del software que traen las computadoras pregrabadas desde su fabricación y que puede estar en memorias de tipo ROM (memorias de solo lectura) o incorporado en su placas de circuitos.
INFORMATICA
Se entiende por informática, palabra formada por la asociación de los términos de INFORmacion y autoMATICA, el conjunto de métodos y mecanismos que tienen como objetivo el tratamiento racional y automática de la información. Ésta, cuyo sentido no se limita sólo al de “noticias”, sino que se extiende también a todos los datos referentes a la comunicación, se compone de un contenido y de una forma o soporte, siendo precisamente este ultimo el que se va a estudiar.
La informática nació cuando el hombre sintió la necesidad de almacenar y ordenar los múltiples conocimientos heredados de sus antepasados para tenerlos a su alcance y utilizarlos a su debido tiempo. El ordenador, maquina destinada a procesar los datos, ha llegado a liberar de los trabajos puramente mecánicos y rutinarios al ser humano que, de este modo, tiene la posibilidad de dedicarse a tareas mas útiles y creativas. Las empresas, grandes y pequeñas, se esfuerzan por disponer de computadoras y, si sus recursos financieros no les permite adquirirlas, recurren al alquiler de las mismas, con o sin derecho de compra, e incluso a la contratación de horas en un centro de calculo especializado. En la actualidad, ningún Estado, aunque carezca de medios, puede prescindir de esta nueva técnica ya que la potencia económica de un país depende en gran parte de ella.
RESEÑA HISTORICA
El desarrollo de la informática se inicio después de la segunda guerra mundial. No obstante, se habían realizado en épocas anteriores investigaciones relacionadas con el tratamiento automático de la información y el inglés Charles Babbage (1792- 1871) unos 50 años antes de los trabajos de Hollerith propuso una maquina a la que le había dado el nombre de “Maquina analítica”. Babbage eran un hombre excéntrico y del mal carácter que paso gran parte de su vida trabajando en vano para completar su increíblemente compleja máquina.
El sueño de Babbage, que para muchos de sus contemporáneos era “la locura de Babbage”, hubiera incluido una entrada por tarjetas perforadas, una unidad de memoria, o almacén, , una unidad aritmética, o molino, la impresión automática de salida, el control
secuencial por programa y una exactitud de 20 cifras. En pocas palabras, Babbage había diseñado un prototipo de computadora que estaba adelantada 100 años a su época.
Lady Augusta Ada Lovelace, hija de Lord Byron, el poeta, ayudó a Babbage. Ella era una brillante matemática y corrigió algunos errores en el trabajo de Babbage e inventó formas novedosas de enfocar el diseño de programas empleando tarjetas perforadas. Por estos descubrimientos muchos la consideran la primera programadora de computadoras. Al morir Babbage, el desarrollo de las computadoras se detuvo hasta 1937 ; las tarjetas perforadas dominaron el mundo del proceso de datos. El norteamericano Hermann Hollerith (1860-1929) construyó en 1885 las primeras maquinas que funcionaban con tarjetas perforadas y el sistema empleado fue perfeccionado por su compatriota Legrand Powers y por el ingeniero noruego Frederick Bull (1882-1925).
En 1937, Howard Aiken, profesor de Harvard, se fijo la meta de construir una maquina calculadora automática que combinara la tecnología eléctrica y mecánica con las técnicas de las tarjetas perforadas de Hollerith. Con la ayuda de estudiantes de posgrado e ingenieros de la IBM, el proyecto se completó en 1944. El aparato terminado se denomino la computadora digital MARK 1. Las operaciones internas se controlaban automáticamente con relevadores electromagnéticos, y los contadores aritméticos eran mecánicos ; así la MARK 1 era una computadora electromecánica. En muchos aspectos era el sueño de Babbage hecho realidad. Esta maquina medieval actualmente se exhibe en la universidad de Harvard.
El primer prototipo de computadora electrónica se concibió en el invierno de 1937-1938 por el doctor John Vincent Atanasoff, profesor de física y matemáticas en Iowa State College. Como ninguna de las calculadoras disponibles en ese entonces era adecuada para sus necesidades, Atanasoff decidió construir la suya. Empleando conceptos de diseño que cristalizaron en su mente a altas horas de una noche de invierno en un bar a la orilla de la carretera en Illinois, Atanasoff formó un equipo con Clifford Berry, su asistente de posgrado, y comenzó a construir la primera computadora electrónica. La llamaron “computadora Atanasoff-Berry”, o ABC. La ABC empleaba bulbos al vacío para almacenar datos y efectuar operaciones aritméticas y lógicas.
Durante 1940 y 1941 Atanasoff y Berry se reunieron con John W. Mauchly y le mostraron su trabajo. Mauchly, que trabajaba en la School of Electrical Engineering de la Universidad de Pennsylvania, comenzó a pensar en la forma de construir una computadora de aplicación general.( La ABC se diseño con el objetivo especifico de resolver sistemas de ecuaciones simultáneas.) Mauchly formó un equipo con J. Presper Eckert, estudiante de posgrado de ingeniería en la Moore School, para organizar la construcción de ENIAC a principios de la década de 1940.
ENIAC fue la primera computadora electrónica de aplicación general que entro en funcionamiento. Financiada por el ejercito de los Estados Unidos, se construyó en la Moore School como proyecto secreto durante la guerra ( al ejercito le interesaba la preparación rápida de tablas de trayectorias de proyectiles). También se utilizaron bulbos al vacío en ENIAC. Aunque pesaba 30 toneladas y ocupaba el espacio de una casa de tres recamaras, ENIAC podría hacer 300 multiplicaciones por segundo, lo que hacia 300 veces mas rápida que cualquier otro dispositivo de la época. Las instrucciones de operación de ENIAC no se almacenan internamente mas bien se introducían por medio de tableros de clavijas e interruptores localizados en el exterior. El ejército utilizó la ENIAC hasta 1955 y después se colocó en el Smithsonian Institucion.
La primera maquina dotada de memoria fue la llamada EDVAC, realizada en la Universidad de Princeton. Ésta era capaz de registrar, conservar y restituir datos en un momento determinado, gracias a un descubrimiento del matemático norteamericano John von Newmann (1903-1957). A la misma época corresponde el ordenador denominado EDASC, que empezó a funcionar en el año 1947 en la Universidad de Cambridge ( Massachusetts).
Los países europeos también contribuyeron de modo notable al desarrollo de la informática. El alemán Konrad Zuse, consiguió poner en funcionamiento las maquinas Z3 y Z4 antes de concluir la guerra, y el francés François Raymond diseño una calculadora automática en 1949. A partir de entonces empezó la comercialización de este tipo de maquinas con las calculadoras de tarjetas perforadas IBM 604 y BULL Gamma 3, con los grandes ordenadores que reciben los nombres de UNIVAC 1 e IBM 701 y con otros mas de tamaño medio, como el IBM 650 y el BULL Gamma de tambor. Todos ellos contenían tubos de vacío, pero, en 1960, estos se sustituyeron por transistores.
En 1965, el modelo IBM 360, sumamente perfeccionado y capaz de resolver los problemas mas complicados , señala el principio de lo que recibe el nombre de tercera generación de ordenadores. Éstos son a la vez numéricos y alfanuméricos, es decir, procesan lo mismo letras que cifras y se prestan tanto al calculo científico como al tratamiento de la gestión.
GENERACIONES DE COMPUTADORAS
PRIMERA GENERACION : Aparece en los años 30-50. Ocupaba cientos de componentes y duraban poco. Procesa la información pero no la almacena. Utilizaba bulbos y engranes.
SEGUNDA GENERACION : Aparece en los años 50-60 utilizaba lenguajes de bajo nivel y transistores . Eran computadoras mas pequeñas que generaban menos calor y sus componentes mas durables. Aparece el software.
TERCERA GENERACION : Abarca los años 60-70. Manejan chips ; permiten hacer operaciones matemáticas y lógicas. Aparecen circuitos integrados, tarjetas impresas ; ocupa cientos de miles de componentes. Se generaliza el uso de las computadoras. Microcomputadoras PROCESO UNICO. Memoria RAM de 16 KB.
CUARTA GENERACION : En los años 70-80 se hicieron mejoras en los componentes, computadoras mas pequeñas pero mas potentes. Se mejoran los microcomponentes y se generalizan. Aparece el disco flexible ; aparece la interactividad (uso de redes). Utilización de monitores. Microcomputadoras MONO - USUARIO. Memoria RAM de 126 KB .
QUINTA GENERACION : Abarca los años 80-90 sus chips son mejorados y la tecnología se vuelve escalable, es decir, que podemos aumentarle la capacidad de memoria, disco duro, instalar un equipo multimedia, cambiar un monitor monocromático (blanco y negro) por uno VGA (color); sin la necesidad de comprar otra computadora.
SEXTA GENERACION : Generación actual. Las novedades que hay en el mundo de la computación como Windows NT que tiene ambiente WEB (red), los monitores TOUCHSCREEN que nos facilitan la utilización de un programa sin la necesidad de utilizar el Mouse, ya que nuestro dedo se convierte en cursor al tocar la pantalla, los programas ACTIVE VOICE que nos facilita la creación de archivos de texto sin la utilización del teclado ya que con este programa con solo dictar el texto la computadora lo transcribe.
ORDENADOR
El ordenador, principal instrumento de la informática, llamado también computadora, es un conjunto de maquinas conectadas eléctricamente entre sí que efectúan, de manera automática y a partir de datos suministrados por el hombre, una serie de operaciones aritméticas y lógicas según los esquemas reunidos en los programas. Su funcionamiento se rige siempre por el mismo principio, aunque existe un gran numero de modelos que se distinguen unos de otros por la forma, el tamaño o la velocidad de ejecución. Los componentes fundamentales de estos aparatos son los dispositivos de entrada y salida, la unidad central de proceso y la memorias.
Dentro del ordenador hay dos parte importantes el software o parte lógica y el hardware o parte física.
SOFTWARE : Parte intangible de un sistema de computación que viene a ser todos los programas que permiten la comunicación entre el ordenador y el usuario.
Se divide en sistemas operativos de aplicación particular y de aplicación general.
Un sistema operativo es el que permite interactuar entre el usuario y la maquina se dividen en traductores y compiladores.
TRADUCTOR : A fines de la década de los 40, cada programa tenia que estar escrito en lenguaje maquina, el único lenguaje que una computadora puede entender directamente. Todos los usuarios tenían que escribir programas compuestos de largas cadenas de ceros y unos para especificar la dirección de información.
Mas tarde, se desarrollaron programas llamados traductores, los cuales aceptaban como entrada cierto lenguaje simbólico o mnemotécnico para luego convertirlo automáticamente en lenguaje maquina. Estos traductores se conocen como ensambladores. Los sistemas de ensamblador, aunque ahorraban al usuario mucho trabajo, no eran atractivos para la mayoría de los usuarios. Era muy molesto tener que especificar simbólicamente , direcciones y códigos de operaciones. Uno tenía que programar todavía en un lenguaje parecido al lenguaje maquina.
El siguiente paso en la automatización de traducción fue la traducción de uno-a-muchos. El traductor de uno-a-muchos permitía al usuario escribir sus instrucciones en un lenguaje de programación mucho mas conveniente ; cada instrucción era automáticamente traducida a varias instrucciones correspondientes en lenguaje de ensamblador o de maquina. Estos primeros traductores de uno-a-muchos fueron los primeros compiladores FORTRAN y ALGOL .
El programa de traducción que transforma un programa en lenguaje de ensamblaje a un programa equivalente en lenguaje maquina se llama ensamblador.
Las instrucciones al ensamblador se llaman pseudo-instrucciones. Cuando el ensamblador encuentra una pseudo-instrucción lleva a efecto una operación de control en vez de una traducción.
La salida del ensamblador es la entrada a un programa llamado el encadenador que es responsable por la resolución de todas las referencias externas entre programas ensamblados independiente mente.
Las ventajas principales de programación en lenguaje de ensamblaje sobre el lenguaje máquina son, que la escritura de programas es mas natural para el humano, y el programador no tiene que preocuparse por trabajos rutinarios. Por ejemplo, si se insertara una nueva instrucción en algún lugar al principio del programa de lenguaje maquina, seria responsabilidad del programador en lenguaje maquina la de cambiar apropiadamente los campos de dirección de referencia de muchas instrucciones que siguen.
COMPILADORES : Es un programa de traducción que, o transforma un lenguaje de alto nivel a un lenguaje de ensamblaje para subsecuente ensamblaje a lenguaje maquina, o que directamente transforma a un lenguaje de alto nivel a un programa equivalente en lenguaje maquina.
Un traductor, por ejemplo un compilador, es activado por el sistema operativo bajo el cual funciona. Cuando es activado, el sistema operativo provee al traductor dos grupos de datos :
1. Un grupo de datos que contiene el programa que se va a traducir, es decir, el programa original.
2. Un grupo de datos que contiene información de control, por ejemplo, qué clase de listados se deben producir.
Ejemplos de compiladores son el FORTRAN y el ALGOL.
SISTEMA OPERATIVO DE APLICACIÓN PARTICULAR : Son los que están hechos para un fin especifico ejemplo programas de contaduría, ingeniería, física, gráficos, etc.
SISTEMA OPERATIVO DE APLICACIÓN GENERAL : Son los que pueden realizar trabajos de cualquier tipo como Word, excel, powerpoint, etc.
HARDWARE : Parte tangible en un sistema que vienen a ser los componentes, es decir, los dispositivos de entrada y salida, el CPU o la unidad central de proceso.
Se divide en tres partes :
❖ Dispositivos de entrada,
❖ Dispositivos salida
❖ Dispositivos entrada /salida.
DISPOSITIVOS DE ENTRADA : Son los componentes físicos que permiten introducir información a la computadora como son el teclado, Mouse, micrófono, scanner, CD rom.
TECLADO : Se divide en 5 partes :
[pic]
1. teclado alfanumérico
2. teclado numérico
3. teclado de funciones
4. teclado de funciones especiales
5. teclado de direcciones
DISPOSITIVOS DE SALIDA : Son los componentes físicos que nos permiten recibir información procesada ( monitor, impresora ).
IMPRESORA : Las impresoras son órganos de salida que escriben las informaciones procedentes de la memoria central del ordenador o los resultados de un tratamiento. Hay que distinguir, entre los diferentes modelos existentes, los que están provistos de rueda, barras o cadenas.
Los primeros, considerados lentos, son capaces de imprimir 120 caracteres o signos, correspondientes a las 120 ruedas que tienen. Cada una de éstas tiene 48 tipos (letras de alfabeto, cifras, signos de puntuación, blancos, etc.) y todas adoptan en un momento dado la disposición idónea para escribir de una sola vez la línea completa.
Los segundos, algo más rápidos, poseen un máximo de 144 caracteres o signos sujetos a una varilla metálica que se mueve horizontalmente de modo rectilíneo y alterno. Un martillo, accionado por un electroimán, presiona la barra contra el papel cuando el tipo seleccionado pasa por delante de la zona de impresión.
Los terceros tienen un sistema análogo al interior, aunque son más rápidos, y están provistos de una banda metálica circular que gira a velocidad constante.
Algunos ordenadores pequeños sustituyen la impresora por un teclado de máquina de escribir, cuyo funcionamiento (cambio de línea y de hoja, retorno del carro) se halla previamente programado para efectuar la impresión.
DISPOSITIVOS DE ENTRADA-SALIDA : Son los componentes físicos que nos permiten recibir e introducir información (disco flexible, monitor, módem, touch screen, CD rider, disco duro).
UNIDAD CENTRAL DE PROCESO : La unidad central de proceso se compone de circuitos aritméticos o lógicos, una memoria central, que contiene los programas y recibe los datos necesarios para llevarlos a cabo, y conexiones con las unidades especializadas.
Los órganos o circuitos de cálculo, que efectúan las operaciones aritméticas y lógicas propias del tratamiento de la información, se encuentran situados en la memoria central y reciben el nombre de sumadoras. Un ordenador lleva a cabo una sucesión de sumas o de restas para obtener un producto o un cociente. Los circuitos suelen ir montados en serie o en paralelo. En el primer caso se repiten las operaciones varias veces, tantas como cifras tiene el mayor de los sumandos, mientras que en el segundo, con una simple operación, se consigue el resultado.
Este último método proporciona, por tanto, mayor rapidez en los cálculos y un rendimiento muy superior al citado anteriormente.
Los órganos de conmutación sirven para abrir o cerrar los circuitos lógicos de las operaciones. En informática sólo existen dos posibilidades, claramente determinadas por la disyuntiva « o » o por la copulativa « y » (A o B, A y B). Cada opción o caso puede, a su vez, ser la combinación de otros varios. Hay tres tipos de órganos de conmutación : uno que invierte los datos de entrada, otro que ejecuta una acción únicamente en presencia de un fenómeno F1, de otro F2 o de los dos, y un tercero que actúa si éstos se verifican de modo simultáneo.
Los órganos de mando, verdadero cerebro de la máquina, son circuitos electrónicos que distribuyen las instrucciones a las diferentes partes de un ordenador y controlan su buen funcionamiento (aceptación de los datos, apertura de fichero, orden de lectura, etc.). Los equipos y dispositivos de la computadora, que constituyen el llamado hardware o maquinaria, se coordinan entre sí mediante el conjunto de los programas, denominado software o logicial.
Se divide en :
UNIDAD ARITMÉTICA LÓGICA : Resuelve problemas lógicos y aritméticos. Tiene 3 registros :
11. REGISTRO OPERANDO 1 o REGISTRO ACUMULADOR : Es el que capta el primer numero de la operación o cuando son varios operandos los va resolviendo y acumulando los valores.
12. REGISTRO OPERANDO 2 : Es el que capta el segundo numero.
13. OPERADOR : Capta los operadores como son los signos :+,*,/,**,=,etc.
UNIDAD DE CONTROL : Se encarga de controlar y verificar tráfico de información. Sus elementos básicos son :
14. REGISTRO DE ESTADO : Capta el numero de acciones que puede realizar nuestra computadora.
15. REGISTRO CONTADOR DE PROGRAMA : Apunta a la primera dirección.
16. REGISTRO DE INSTRUCCION : Toma el contenido de la dirección.
17. RELOJ : Asigna ciclos de reloj en nanosegundos.
18. INTERPRETE : Traduce y ejecuta el programa.
Cuando instalamos un programa el COMMAND.COM lo manda a la memoria RAM y el registro de estado manda la señal al registro contador de programa, el cual va al decodificador de direcciones de la memoria RAM por medio del bu de dirección y capta la primera dirección del programa ; después manda la señal al registro de instrucción quien por medio del bu de datos va a la celdas de la memoria principal y toma los datos de la celda cuya dirección es la que le especifico el registro contador de programa, luego manda la información al interpreta quien traduce y ejecuta el programa y por medio del bu de control lo manda al resto de los componentes.
Existe también el bu general que realiza las funciones de los buses de control, dirección y de datos. La ventaja de este tipo de bu es que es mas económico pero su desventaja es que se tiene que realizar el mapeo de direcciones en memoria ya que puede que las direcciones de la memoria sean las mismas direcciones que los periféricos y para evitar confusiones se cancelan las direcciones en memoria que sean iguales a las de los componentes.
MEMORIA : La memoria es un elemento destinado a almacenar de manera automática las informaciones o los resultados parciales para utilizarlos luego en el momento oportuno.
CLASES DE MEMORIAS : El ordenador dispone de dos clases de memorias : central y auxiliares.
La primera, que contiene los programas en curso de ejecución y algunos datos, interviene en todas las transferencias de información y es accesible desde la unidad central de tratamiento.
Las segundas, al permitir el almacenamiento de ficheros, aumentan la capacidad del ordenador y suelen ser de disco o de tambor magnético.
ANILLOS DE FERRITA : El 95% de las memorias centrales se construyen con anillos de ferrita, dispuestos en cada una de las intersecciones de una red metálica. Al tener este material propiedades electromagnéticas, el paso de la corriente por los conductores magnetiza y desmagnetiza los anillos en millonésima de segundo.
MEMORIAS DE CINTA, DE DISCO Y DE TAMBOR : La cinta magnética permite almacenar numerosas informaciones, pero el tiempo de restitución de éstas se considera demasiado largo en muchos casos.
Este inconveniente no existe, en cambio, en las memorias de disco o de tambor. Las primeras, con una capacidad de decenas de millones de caracteres, consisten en una pila de discos que contienen datos por ambas caras, cuya restitución se obtiene muy rápidamente por medio de una cabeza de lectura. Las segundas constan de un cilindro cubierto con una capa magnética en la cual se graban las informaciones en pistas circulares. La localización del dato requerido se efectúa con una cabeza de lectura en unos diez milisegundos.
TRATAMIENTO DE LA INFORMACION
El tratamiento de la información o proceso de datos por medios automáticos responde a la necesidad de transformar, de modo rápido, económico y seguro, ciertos datos que se conocen para intentar obtener resultados que puedan emplearse de forma directa o indirecta. Se aplica así a todas las actividades humanas, científicas, administrativas, industriales, comerciales, medicas, sociales, profesionales, deportivas y artísticas.
TOMA DE DATOS : La información consta, esencialmente de símbolos de carácter visual (grafismos) o auditivo (fonemas) que representan los objetos o los hechos o bien las relaciones existentes entre ambos. Actualmente la informática se basa sobre todo en los primeros, aunque algunos procedimientos muy recientes utilizan los segundos.
Los símbolos gráficos empleados en Europa son las 26 letras del alfabeto, diez guarismos decimales, algunos signos de puntuación y una serie de símbolos matemáticos. Las palabras están formadas por agrupaciones de letras, y las oraciones por conjuntos de palabras organizadas según las reglas gramaticales. La yuxtaposición de cifras constituye los números, que se rigen por leyes aritméticas.
La información no puede procesarse en un ordenador en forma de símbolos gráficos y debe, por tanto, sufrir una transformación mediante un código adaptado a las operaciones de transmisión, almacenamiento y tratamiento. Este es generalmente el código binario, sistema de numeración de base 2 fundado en el bit o unidad de información que solo toma dos valores (0,1 o verdadero, falso).
Existen códigos que nos permiten a nosotros interactuar con la computadora como son el código ASCII y el EBCDIC que son códigos que tienen los equivalentes de todas las letras, números y signos en su valor binario para que la computadora lo “entienda”.
Las unidades de información que tiene la computadora son :
BIT : (binary digit). Es la unidad mínima de información que contiene la computadora.
BYTE : Es el conjunto de 8 bits ; equivale a un carácter.
KILOBYTE o KB : Es el conjunto de 1024 bytes.
MEGABYTE o MB : Es el conjunto de 1024 KB .
GIGABYTE o GB : Es el conjunto de 1024 MB .
Un dato es la expresión general que describe los objetos con los cuales opera una computadora.
Los diferentes objetos de información con los que un programa trabaja se conocen colectivamente como datos. Todos los datos tienen un tipo asociado con ellos.
TIPOS DE DATOS : Características definidas de los variables de datos.
Aun cuando los datos e instrucciones pueden tener la misma forma o expresión, se hace una distinción funcional entre ellos, una instrucción comando a la computadora para que realice una operación mientras que los datos representan información. Las computadoras solo procesan y manejan datos :
ENTRADA SALIDA DE
DATOS PROCESO INFORMACIÓN
La asignación de tipos a los datos tienen 2 objetivos principales :
1) Detector de errores de operación
2) Determinar como ejecutar las operaciones
El tipo de un dato determina la naturaleza del conjunto de valores que puede tomar una variable o constante. Otro concepto importante a tener en cuenta es la representación interna de los números, o al menos el espacio de memoria ocupado por una variable de un tipo dado.
Los datos a procesar por una computadora pueden clasificarse en :
A) ESTATICOS
B) DINAMICOS
DATOS ESTATICOS : Debido a que los variables son direcciones simbólicas de posiciones de memoria ; Esta relación entre nombres de variables y posiciones de memorias es una relación estática que se establece durante la ejecución, es decir, el valor de la variable puede cambiar, las variables por sí mismas no se pueden crear ni destruir durante la ejecución. En consecuencia, las variables consideradas hasta este punto, se denominan variables estáticas.
En algunas ocasiones, sin embargo, no se conoce por adelantado cuanta memoria se requerirá para un programa. En esos casos es conveniente disponer de un método para adquirir posiciones adicionales de memoria a medida que se necesiten durante la ejecución del programa y liberarlas cuando no se necesiten, las variables que se crean y están disponibles durante la ejecución de un programa se llaman variables dinámicas.
Los datos estáticos pueden ser :
A) SIMPLES
B) ESTRUCTURADOS
Los tipos de datos simples o primitivos significan que no están compuestos de otras estructuras de datos ; Los tipos de datos simples pueden ser organizados en diferentes estructuras de datos : estáticos y dinámicos.
Las estructuras de datos estáticos son aquellas en las que el tamaño ocupado en memoria se define antes que el programa se ejecute y no puede modificarse dicho tamaño durante la ejecución del programa. (El tamaño ocupado en memoria es fijo).
Una estructura de datos es una colección de datos, donde cada dato puede tomar diferente tipo de dato.
Una característica importante que diferencia a los tipos de datos es la siguiente : los tipos de datos simples tienen como característica común que un identificador (nombre) puede representar a múltiples datos individuales, pudiendo cada uno de estos ser referenciados independientemente.
Los tipos de datos simples son los siguientes :
a) NUMERICOS (ENTEROS, REALES)
b) LOGICOS
c) CARÁCTER
a) DATOS NUMERICOS : El tipo entero es un subconjunto finito de los números enteros. Los enteros son números completos, no tienen componentes fraccionarios o decimales y pueden ser negativos y positivos. Ejemplo :
1) 5 2) 2456 3) 48763
DATOS LOGICOS : El tipo lógico también se le denomina booleano, este tipo de dato solo puede tomar uno de dos valores : cierto o verdadero (true) y falso (false). Este tipo se emplea para representar las alternativas (si/no) a determinadas condiciones. Ocupa un byte en memoria.
DATOS TIPO CARÁCTER : Es el conjunto finito y ordenado de caracteres que la computadora reconoce.
Un dato tipo carácter contiene un solo carácter, la mayoría de las computadoras reconoce los siguientes caracteres :
Caracteres alfabéticos (A.....Z, a.....z)
Caracteres numéricos ( 0.....9)
Caracteres especiales ( +, . , : , $, ?, !, &, ...etc.)
TIPOS DE REDES
REDES : Define el intercambio de información dentro de una red de teleproceso. Se ocupa del agrupamiento de tramas en paquetes, del direccionamiento y de la detección y corrección de errores.
LAN : Redes de área local.
WAN : Redes de área amplia.
LAN : Son aquellas que están establecidas en un área determinada. Pueden tener de L a N usuarios. A cada terminal que atienda un usuario va a ser un nodo. Tiene que tener cuando menos un servidor, un nodo, conectores necesarios, tarjetas de red necesarios, línea de comunicación, sistema operativo de red, un DOS, software de aplicación para red y protocolos. (Los anteriores son los elementos básicos para una red).
LINEA: Medio que me permita transportar información de un lugar a otro.
CANAL: Cuando la línea contiene información.
Las líneas más comunes son :
Cable coaxial: Menos eficiente, más económico, par trenzado o telefónico.
Fibra óptica: Más eficiente, más caro.
Integridad: Que el paquete de datos que estoy mandando por la línea debe ser igual cuando llegue.
TOPOLOGIA DE REDES
TOPOLOGIA: La forma física en que está instalada la red.
DE BUS: Tiene un servidor dedicado, gran capacidad de memoria, procesador rápido, almacenamiento amplio de memoria secundaria, capacidad de RAM debe ser amplia. Es muy común que esté instalado con cable coaxial y tiene unos conectores que se llaman BNC, requiere además de un tapón BNC terminal.
DE ANILLO : Es una variante de la de bus, solo que para evitar el tapón BNC y las caídas de red, la última parte se conecta a la terminal. La forma más común de instalación es con cable coaxial.
DE ESTRELLA : Nos evita problemas de que se caiga la red. Se requiere de un concentrador quien distribuye la señal a cada uno de los nodos.
DE ESTRELLA DE INTERCONECTIVIDAD TOTAL : Se tiene uno o más servidores y cada uno de los nodos tiene conectividad con los demás.
DE ESTRELLA DE INTERCONECTIVIDAD PARCIAL : El servidor está conectado directamente con cada uno de los nodos pero los nodos no están interconectados entre sí.
DE ARBOL : Es práctica cuando no se quiere invertir en un servidor. Todas las computadoras tienen las mismas características en cuanto a capacidad de almacenaje, procesador, etc.
HIBRIDAS O MIXTAS : Es donde se pueden combinar las topologías
Modos de transmisión (LAN)
TRANSMISION ASÍNCRONA : Envía la informacion, octeto a octeto, en cualquier momento. Cada uno de ellos va precediendo de un bit de arranque y seguido de uno de parada para ser identificados por el receptor. Las velocidades de transmision permitidas en este modo son muy bajas, inferiores a 1200 bits por segundo.
TRANSMISION SÍNCRONA : Es en la que el emisor y el receptor disponen de sendos relojes, por medio de los cuales controlan la duración constante de cada octeto transmitido. Estos se envian de una forma continuada, sin ninguna separacion. En este modo se puede tener cualquier velocidad de transmision por alta que sea. Son velocidades tipicas 2400, 4800, 9600 y 19200 bits por segundo.
SIMPLEX : la transmision de datos se realiza en un unico sentido, desde una estacion emisora a una estacion receptora, que generalmente corresponde a una terminal como origen y una computadora central como destino, o bien una computadora como origen y una impresora o unidad de visualizacion como destino. Este modo de transmision es el menos utilizado.
SEMIDUPLEX O HALFDUPLEX : Se denomina así al modo de transmision en el que el envio de datos se realiza en ambos sentidos, pero no simultaneamente. Por tanto, los equipos conectados con este modo son ambos emisor y receptor, aunque en cada momento realizan una sola de estas funciones, alternando el sentido de la comunicación cada vez que sea necesario. Es el modo mas utilizado, por permitir comunicación en ambos sentidos a un costo reducido.
DUPLEX O FULLDUPLEX : mediante este modo se establece la comunicación de datos a traves de la linea de teleproceso en ambos sentidos simultaneamente, lo que permite una mayor agilizacion de las operación de recepcion de datos y envio de resultados. A pesar de ser el mas eficiente, no es el mas utilizado, debido al costo superior que implica el uso de equipos y redes de telecomunicacion mas complejos.
Medios de transmision : La información circular por la computadora en forma de señal digital, esto es, codificada utilizando un alfabeto de dos símbolos que corresponden a dos intensidades diferentes de corriente eléctrica . Esta forma de transmitir información se ha mostrado inadecuada para el caso de comunicaciones a grandes distancias, en cuyo caso es enviada en forma de señal analógica. Para ello no solo se han diseñado medios de transmisión especializados, sino que además se han podido utilizar los medios ya existentes en telefonía y telegrafía.
Actualmente los medios físicos más utilizados en transmisión de datos son los siguientes :
CABLES DE PARES: Empleados, asimismo, en comunicaciones telefónicas, consisten en dos hilos conductores recubiertos de material aislante y trenzados a fin de disminuir las posibles interferencias.
CABLES DE CUADRETES: Similares a los anteriores, pero utilizando cuatro hilos conductores, de dos tipos diferentes según el trenzamiento.
CABLES COAXIALES: Formados por un hilo conductor central y otro cilíndrico exterior (trenzado de hilos o lámina de aluminio). El cable está recubierto de material aislante, ocupando también el espacio entre el cilindro conductor y el hilo central.
REDES DE AREA AMPLIA (WAN)
Clasificación:
Regionales: Influencia en la región
Nacional: Influencia en el país
Mundial: Todo el mundo (Internet)
Todas las redes WAN requieren un emisor receptor, un decoder y un medio. Los medios para conectar un WAN son microondas, vía satélite y fibra óptica.
CONCLUSIONES
La aparición y desarrollo de la informática en la segunda mitad del siglo XX han producido una transformación bastante profunda en la vida del hombre y han provocado en varios casos una reacción adversa.
No se acepta fácilmente la intrusión del ordenador en numerosos sectores de la actividad humana, en especial los considerados como privados, porque esto atenta en cierto modo contra las libertades individuales. La opinión pública piensa en general que el uso de la computadora por los organismos oficiales constituye un instrumento coactivo para el pago de las multas o de las deudas fiscales y no ve con agrado la posibilidad que existe de confeccionar, en un momento determinado, un inmenso fichero nacional en el que aparezcan registrados los datos personales y toda clase de antecedentes de cada uno de los ciudadanos.
Resulta necesaria, por consiguiente, una legislación destinada a poner coto a los abusos que podrían cometer el Estado o las empresas en detrimento de las personas. Dichas leyes deberían prever una serie de medidas encaminadas a controlar y a limitar el contenido de los ficheros, así como a reglamentar el acceso a los mismos. La informática, al conducir a una mayor automatización, suscita cierta animadversión por creerse que puede traer consigo la supresión de determinados puestos de trabajo. Este inconveniente, originado por el principio económico de buscar siempre la mayor rentabilidad, desaparece, sin embargo, cuando los gobiernos tienen programas de reconversión para los empleados perjudicados.
Cabe recordar además que, si bien esta tecnología suprime las tareas subalternas, por otra parte requiere la participación de un personal de muy alto nivel.
Muchas de las críticas formuladas se deben al desconocimiento de la capacidad y de los límites de los ordenadores, así como de los mecanismos socioeconómicos que impulsan el desarrollo de la informática. Una información adecuada desde la edad escolar sería, por consiguiente, sumamente deseable, porque contribuiría a transformar la actitud un tanto negativa que el público tiene en general respecto a esta nueva especialidad.
Para enviar información se requiere de :
EMISOR: Manda información
CANAL O MEDIO: Es donde viaja la información
RECEPTOR: Recibe la información.
BIBLIOGRAFIA
www.google.com.ve/buscadores
www.rincondelvago.com/buscadores
www.monografias.com
INSTITUTO TECNOLOGICO SUPERIOR DE XALAPA
NOMBRE DEL PROYECTO:
DISEÑO E INSTRUMENTACIÓN DE UN SISTEMA DE SINCRONIZACIÓN DISTRIBUIDO
CAMPOS FELIDOR GUSTAVO EDUARDO
047O0482
INGENIERIA ELECTRONICA
0442281128562
8100173
ASESOR INTERNO
ING DANIEL HERNÁNDEZ VENTURA
ASESOR EXTERNO
ING CORNELIO GARCÍA FERNÁNDEZ
ENERO DEL 2009
ÍNDICE
I. INTRODUCCION. 7
II. PLANTEAMIENTO DEL PROBLEMA. 8
III. OBJETIVO GENERAL 9
IV. OBJETIVOS ESPECÍFICOS 9
V. JUSTIFICACIÓN 10
CAPITULO I ANTECEDENTES 11
1.1. INFORMACION 12
1.2. EDUCACION 13
1.3. CAPACITACION 13
1.4. CULTURA 14
1.5. ENTRETENIMIENTO 15
1.6. MISION17
1.7. VISION 17
CAPITULO II MARCO TEORICO 18
2.1 PROTOCOLO NTP 19
2.1.1 ENCAPSULADO NTP. 20
2.1.2 CONFIGURACIONES NTP. 21
2.1.3 ESQUEMA DE SINCRONIZACIÓN 23
2.2 GPS 25
2.2.1 FUNCIONAMIENTO 26
2.2.2 TRIANGULACIÓN 27
2.2.3 MEDICION DE LAS DISTACIAS DE LOS SATELITES. 30
2.2.4 APLICACIONES DEL GPS 32
2.3 HUSOS HORARIOS 33
2.3.1 HUSOS HORARIOS DE MÉXICO. 34
2.4 TIEMPO SIDERAL 35
2.5 COMUNICACIÓN SERIAL. 36
2.5.1 DEFINICION. 36
2.5.2 MODOS DE TRANSMISIÓN 37
2.5.2.1 TRANSMISIÓN SIMPLEX38
2.5.2.2 TRANSMISIÓN HALF-DUPLEX 38
2.5.2.3 TRANSMISIÓN FULL-DUPLEX 39
2.5.3 COMUNICACIÓN ASINCRONA 40
2.5.3.1 BIT DE INICIO Y BIT DE PARO. 41
2.5.3.2 REGLAS DE TRANSMISIÓN ASINCRONA 42
2.5.4 VELOCIDAD DE TRANSMISIÓN 43
2.5.5 TRANSMISIÓN SINCRONA 45
2.5.6 DETECTAR ERRORES EN LA COMUNICACIÓN. 46
2.5.7 GENERADORES Y DETECTORES DE PARIDAD 47
2.5.7.1 PARIDAD PAR 47
2.5.7.2 PARIDAD IMPAR 49
2.5.7.3 METODO CHECKSUM 51
2.5.8 INTERFAZ RS232 52
2.5.8.1 CONSTRUCCION FISICA 53
2.5.8.2 VELOCIDAD 55
2.5.8.3 CONECTORES 56
2.5.8.4 DESCRIPCION DE TERMINALES. 56
CAPITULO III DESARROLLO DEL PROTOTIPO 59
3.1 VISUAL BASIC 60
3.2 DESARROLLO DEL DISPOSITIVO MASTER 64
3.2.1 RECEPCIÓN DE LOS DATOS. 65
3.2.1.1 MICROCONTROLADOR 66
3.2.1.2 VISUALIZACION EN UN LCD 71
3.2.2 ENVIÓ DE DATOS. 76
3.3 DESARROLLO DEL DISPOSITIVO SLAVE 77
3.3.1 RECEPCION DE DATOS. 77
3.3.2 COMUNICACIÓN ENTRE MICROCONTROLADORES 78
CAPITULO IV PRUEBAS Y AJUSTES. 83
4.1 PRUEBAS 84
1.1.2 PRUEBA DEL PROGRAMA EN VISUAL BASIC. 84
1.1.3 PRUEBA DE COMUNICACIÓN ENTRE VISUAL BASIC Y DISPOSITIVO MASTER 85
1.1.4 PRUEBA DE ENVIO DE DATOS ENTRE MICROCONTROLADORES. 86
1.1.5 PRUEBA DEL DISPOSITIVO SLAVE 88
CONCLUSIONES. 89
ANEXOS 91
BIBLIOGRAFIA. 97
INDICE DE IMÁGENES
Imagen 1.- Logotipo de Veracruz al natural 18
Imagen 2.- Veracruz Agropecuario 19
Imagen 3.- Tierra Nuestra Veracruz 19
Imagen 4.- Programa "El Molcajete" 20
Imagen 5.-Protocolo NTP 26
Imagen 6.- Esquema de Configuraciones 27
Imagen 7.- Esquema jerárquico de NTP 29
Imagen 8.- Funcionamiento del GPS 31
Imagen 9.- Triangulación de los Satelites 33
Imagen 10.- Triangulación del primer Satélite 33
Imagen 11.- Triangulación con el segundo Satélite 34
Imagen 12.- Triangulación con el tercer Satélite 34
Imagen 13.- Husos Horarios 38
Imagen 14.- Husos Horarios en México 40
Imagen 15.- Tiempo Sideral 41
Imagen 16.- Modo de comunicación en serie 42
Imagen 17.- Transmisión Simplex 43
Imagen 18.- Transmisión Half-Duplex 44
Imagen 19.- Transmisión Full-Duplex 44
Imagen 20.- Modo de comunicación Asincrono 46
Imagen 21.- Formato de Transmisión Asíncrona 46
Imagen 22.- Formato básico de Transmisión asíncrona 48
Imagen 23.- Transmisión asíncrona con velocidad menor que la máxima posible49
Imagen 24.- Transmisión asíncrona con la velocidad máxima posible 49
Imagen 25.- Transmisión sincrónica 50
Imagen 26.- Inserción automática de caracteres de sincronismo51
Imagen 27.- Detector de paridad 52
Imagen 288.- Generador de Paridad 53
Imagen 29.- Ejemplo de Paridad Impar 54
Imagen 30.- Ejemplo de paridad Impar 55
Imagen 31.- Secuencias de transmisión Impar 55
Imagen 32.-Ejemplo de error de recepción en paridad impar 55
Imagen 33.- Conectores hembra y macho para el protocolo RS232 58
Imagen 34.- Conector macho y hembra DB9 61
Imagen 35.- Vista real de un conector DB9 macho 61
Imagen 36.- Numeración de pines 62
Imagen 37.- Vista inicial de Visual Basic 66
Imagen 38.- Diagrama de flujo del funcionamiento del programa en Visual Basic 67
Imagen 39.- Vista del reloj digital programado en Visual Basic 68
Imagen 40.- Convertidor USB-Serial para la computadora 69
Imagen 41.- Esquema de funcionamiento del circuito Max232 70
Imagen 42.- Vista del Max232 en placa 71
Imagen 43.- Esquema de funcionamiento de un Microcontrolador 72
Imagen 44.- Microcontrolador (ATmega32) 73
Imagen 45.- Diagrama de Flujo del funcionamiento del programa en el microcontrolador74
Imagen 46.- Capacitores y Cristal utilizados 75
Imagen 47.- Diagrana de conexion del cristal 76
Imagen 48.- Conexión del cristal y capacitores en el microcontrolador 76
Imagen 49.- LCD 77
Imagen 50.- Diagrama de conexión del LCD 78
Imagen 51.- Conexion del LCD con el microcontrolador 78
Imagen 52.- Modo de funcionamiento del dispositivo Master 79
Imagen 53.- Conexión del Dispositivo completo 80
Imagen 54.- Conexión del Dispositivo Master 81
Imagen 55.- Diagrama de conexiones de TXD y RXD 82
Imagen 56.- Funcionamiento del RXD en el microcontrolador 83
Imagen 57.- Conexión de mas dispositivos Slaves 83
Imagen 58.- Displays utilizados 85
Imagen 59.- Conexiones de Display Ánodo y Cátodo 85
Imagen 60.- Conexion del Decodificador con el display de 7 segmentos 86
Imagen 61.- Conexion del microcontrolador con el display de 7 segmentos 87
Imagen 62.- Problemas de compatibilidad 89
Imagen 63.- Parámetros del MsComm en Visual Basic 91
Imagen 64.- Funcionamiento Slave 93
Imagen 65.- Foro de estudio de deportes de RTV 96
Imagen 66.- Estudio de Noticias de RTV 97
Imagen 67.- Master de Televisión 97
INDICE DE TABLAS
Tabla 1.- Distribución de las horas para la programación 22
Tabla 2.- Paridad par 53
Tabla 3.- Paridad impar 54
Tabla 4.- Señales RS-232 más comunes 58
Tabla 5.- Valores de entradas y salidas para BCD 86
Tabla 6.- Ejemplos de UBRR y frecuencias 90
INTRODUCCION.
En la actualidad la electrónica avanza cada día a grandes pasos en muchas de las áreas en donde el ser humano tiene contacto, como por ejemplo en la casa para hacer más reconfortante la vida del ser humano, en las industrias, donde se requieren mayor seguridad, y para la automatización de maquinaria etc.
En el caso de Radiotelevisión de Veracruz que es el primer canal cultural a nivel estatal, en el cual se cuenta con una diversa programación de información, educación, capacitación, cultura y entretenimiento es de mucha importancia contar con un cierto orden en cuanto a la organización de cada una de las personas que laboran dentro de la empresa, y así mismo tener un control de los horarios en donde cada uno de ellos participan constantemente, en el cual la participación de la electrónica juega un importante papel.
Para esto, se realizo un prototipo de un dispositivo electrónico que a lo largo de este escrito se le llamara Master, en el cual será capaz de adquirir automáticamente la hora de la computadora del usuario, para a si después poder mandarla hacia deferentes dispositivos electrónicos que los llamaremos Slave y mantener un estado de sincronía entre ambos y a su vez poder mantener un error de +/- 1% diario, en el cual este error se corregirá al termino de cada día.
Todo esto se realizo bajo un protocolo de comunicación serial RS-232, en donde este protocolo los datos se transmitirán en una sola línea, por lo que hace que sea mucho menos costoso y contara con menor disposición a errores.
PLANTEAMIENTO DEL PROBLEMA.
La realización del proyecto surge de la necesidad de tener sincronizados más de dos sistemas físicamente distantes, para que las operaciones que realicen tales sistemas ocurran en instantes de tiempo conocidos y en tiempos con la exactitud requerida por la empresa de Radiotelevisión de Veracruz (RTV). Para esta empresa es de suma importancia efectuar sus labores de transferencia de información de tal manera que todos los sistemas de comunicación mantengan una sincronía exacta.
A la fecha, cada foro en RTV es una isla respecto a los otros foros. En cada foro se tiene un horario que puede llegar a diferir significativamente del resto de los foros. Como en conjunto, se requiere coordinar las actividades de estos foros, es una necesidad que todos ellos compartan el mismo horario, que la hora de uno a otro foro no sea distinta. Pues de seguir esta situación, se continuará con los problemas de coordinación existentes.
El utilizar relojes independientes y que de inicio se calibren a la misma hora, ha demostrado según la experiencia del asesor externo, ser una solución a muy corto plazo, pues situaciones como al alteración intencional de estos relojes, el retraso o error debido a su fabricación o por decaimiento de las baterías, agregaba más trabajo de supervisión de todos y cada uno de los foros.
Y esta supervisión es aún más difícil cuando se trata de que revisar foros distantes entre sí por más de 90 metros. Por otro lado, continua el factor humano que es una fuente potencial de errores, al ser personal de la empresa el encargado de ajustar, a su entender, los relojes de cada uno de los foros.
De lo antes descrito, es que surge la imperiosa necesidad de contar con un dispositivo electrónico llamado Master que sea capaz de generar un tiempo específico para una sincronización estable con otros dispositivos localizados en los foros y a los que se les da el nombre operativo de Slaves. El MASTER debe de ser configurable por un único usuario, para poder establecer la hora en la cual se tiene que iniciar el Master y que será comunicada a cada SLAVE.
OBJETIVO GENERAL
Diseñar e instrumentar un dispositivo electrónico llamado MASTER capaz de comunicarse en una red con otros dispositivos electrónicos conocidos como SLAVES, y mantener con estos últimos una sincronización de sus relojes con un retraso no mayor a los 100 mS.
OBJETIVOS ESPECÍFICOS
Diseñar e instrumentar el dispositivo MASTER, que sea capaz de mantener y mostrar la hora actual con error de menos del 1% diario.
Rediseñar el MASTER para que sea posible reconfigurar su hora de inicio a través del uso de botones.
Utilizar dispositivos electrónicos de comunicación de dato para establecer un canal de comunicación entre el MASTER y los SLAVES.
Diseñar e instrumentar el dispositivo SLAVE capaz de replicar la hora del master.
Lograr que la transmisión de los datos generados por el dispositivo Master sean recibidos por los dispositivos Slaves utilizando un protocolo de comunicación serial.
JUSTIFICACIÓN
La problemática de la empresa es que en la actualidad no cuentan con los dispositivos necesarios para la sincronización de los diferentes foros de la empresa, esto es necesarios para que los programas de TV y de RADIO sean transmitidos en los horarios adecuados y que no exista un desfase entre una transmisión y otra.
Y es por esto que se diseñaran e implementara un dispositivo electrónico llamado Master, que será el encargado de generar los pulsos sincronos. Además se diseñaran e implementaran dispositivos electrónicos llamados Slaves para cada uno de los foros que serán sincronizados por el Master.
La distancia que habrá entre un dispositivo MASTER y un dispositivo SLAVE es de aproximadamente 90 metros y esto puede significar retraso en tiempo para poder establecer la comunicación. Debido a esto se deberá seleccionar un medio de comunicación capaz de soportar las diferentes interferencias que existen dentro de la empresa.
CAPITULO I ANTECEDENTES
El 6 de enero de 1980, el Licenciado José López Portillo inauguró oficialmente las instalaciones del primer canal cultural estatal, no sólo de México sino de América Latina, en el Estado de Veracruz, con las siglas XHGV y en la frecuencia de Radiotelevisión de Veracruz, inicia sus operaciones tratando de ser una alternativa de comunicación para los veracruzanos.
Su programación se divide en cinco bloques:
• Información
• Educación
• Capacitación
• Cultura
• Entretenimiento
1 INFORMACION
Dar a conocer a la población lo que acontece en la entidad, es tarea fundamental del equipo de comunicadores que laboran en los puntos más apartados del territorio, para llevar a los hogares veracruzanos la información de los sucesos que marcan nuestra historia.
Con la transmisión de todos los eventos de interés general, el televidente participa de los aspectos sociales, económicos y políticos que conforman la vida de nuestro estado.
Para llevar a cabo esta tarea la Subdirección de noticias y programas informativos, cuenta con recursos acordes a la nueva tecnología en comunicación como son: Telex, señales vía satélite, cámaras portátiles, cabinas de grabación y edición y videoteca propia.
2 EDUCACION
En la renglón educativo, Radiotelevisión de Veracruz ha sido precursor en nuestro país con la creación de un sistema para producción y transmisión de teleclases de nivel bachillerato (TEBA).
[pic]
Imagen 1.- Logotipo de Veracruz al natural
Este sistema fundado en 1980 brinda servicios a más de 5,000 alumnos que cursan sus estudios en los 78 centros en activo. De 1982 a la fecha han egresado 9 generaciones con un total de 12,000 bachilleres.
3 CAPACITACION
El estado de Veracruz se destaca por poseer, además de su estratégica posición frente al litoral del Golfo de México, un vasto potencial en recursos renovables como la pesca, la agricultura y la silvicultura.
Por tal motivo resulta necesaria la realización y transmisión de programas específicos que apoyen las metas y acciones que han contemplado el Gobierno del Estado.
[pic]
Imagen 2.- Veracruz Agropecuario
4 CULTURA
Veracruz es un estado con una incalculable herencia histórica, cultura y política que todos sus habitantes están obligados a conocer.
[pic]
Imagen 3.- Tierra Nuestra Veracruz
Repartidas en las principales ciudades del estado, existen numerosos lugares que sirven de sede para la presentación de grupos artísticos: galerías de arte, teatros, auditorios, salas de conferencias, etc.
Las expresiones artísticas en sus diversas facetas, son captadas y transmitidas a un gran número de veracruzanos.
Esta tarea de difundir la cultura es uno de los principales objetivos de la televisora estatal.
5 ENTRETENIMIENTO
La diversión forma parte importante de las emisiones, de esta forma, se penetra en el gusto del televidente. Los programas de entretenimiento ayudan a conservar el equilibrio de la barra de programación y atraen de la atención del público.
[pic]
Imagen 4.- Programa "El Molcajete"
La operación de una estación televisora, requiere, además de los equilibrios y el mantenimiento necesarios, una organización interna que permita el desempeño eficiente de todos sus integrantes y cumpla así co las metas y objetivos que se plantean.
Las políticas de producción, programación, administración y, en su caso, de comercialización, las determina directamente el Gobernador del Estado a través de la Coordinación General de Comunicación Social.
Por su parte la Dirección General cuenta con cuatro áreas específicas que conforman el conjunto operativo de la institución.
Subdirección técnica: Encargada de la transmisión, operación y mantenimiento del equipo técnico.
Subdirección de noticias y Programas Informativos: Encargada de la elaboración y producción de noticiarios, reportajes y programas informativos.
Subdirección de Producción y Programación: Encargada de la elaboración, producción y programación de las series de televisión.
Subdirección Administrativa: Encargada del control de pagos, personal, transporte, almacén, vigilancia y mantenimiento de las instalaciones del canal.
Así de manera conjunta, Radiotelevisión de Veracruz apoyado con sus empleados, se esmera día a día en ofrecer al pueblo veracruzano, un mejor servicio de televisión, al asumir cada unos de sus trabajadores la responsabilidad que representa el trabajo de la comunicación.
La programación de Radiotelevisión de Veracruz está constituida por programas de diversas características, pero con un mismo objetivo, brindar al televidente una alternativa de comunicación.
Su cuenta con una transmisión de 100 horas a la semana, de las cuales 76 corresponden a la producción local y 24 a producciones externas.
De acuerdo a sus características se puede dividir de la siguiente manera:
|GENERO |HORAS POR SEMANA |
|Programas educativos |24:00 |
|Películas |18:30 |
|Entretenimiento |05:00 |
|Programas informativos |15:00 |
|Programas infantiles |08:30 |
|Culturales |07:00 |
|Series |04:00 |
|Periodísticos |01:30 |
|Agropecuarios |01:00 |
|Deportivos |08:00 |
|Musicales |06:30 |
|Servicio social |01:00 |
|TOTAL |100:00 HORAS |
Tabla 1.- Distribución de las horas para la programación
6 MISION
Producir y transmitir por radio y televisión programación de alta calidad constituyendo foros de expresión idóneos para fortalecer y ampliar los medios de participación social, el diálogo y la comunicación que debe prevalecer entre los distintos sectores de la sociedad, con el propósito de fortalecer la identidad y unidad de los veracruzanos y el aprecio por sus valores, logrando con ello, objetivos de orden social y cultural en beneficio de la sociedad veracruzana.
7 VISION
Contribuir al mejoramiento de la calidad de vida de los veracruzanos a través del impulso a la cultura y la educación por medio de la radio y la televisión.
CAPITULO II MARCO TEORICO
2.1 PROTOCOLO NTP.
El estándar de escala de tiempo usado por muchos países es el UTC (Coordinated Universal Time), que esta basado en la rotación de la tierra alrededor de su eje, y el calendario Gregoriano, que esta basado en la rotación de la tierra alrededor del sol. La escala de tiempo UTC esta en concordancia al TAI (International Atomic Time) insertando saltos de segundos en
intervalos de 18 meses aproximadamente. La hora UTC esta divulgada de diferentes maneras, incluyendo sistemas de navegación por radio y satélite, módems, relojes portátiles, etc.
El propósito de estos receptores es estar disponible para muchos de los servicios de divulgación incluyendo el Global Position System (GPS) y otros servicios utilizados por los gobiernos de los países. Por razones de costo y conveniencia, no es posible que equipar cada computadora con uno de estos receptores. Sin embargo, es posible equipar un número de computadoras actuando como servidores primarios para sincronizar a la mayoría de servidores secundarios y clientes conectados por una red común. Para hacer esto, es necesario un protocolo de red de sincronización de tiempo, que pueda leer un servidor de hora, transmita la lectura a uno o mas clientes y ajuste el reloj de cada cliente como sea necesario. Se pueden encontrar varios protocolos que hagan esto entre ellos el NTP (Network Time Protocol).
Por tanto podemos decir que el NTP sirve para sincronizar relojes de hosts y routers en Internet. Este protocolo se estableció en los años 80 y era para Unix y después salió uno similar SNTP (Short Network Time Protocol) para Windows, cuyo objetivo era poder sincronizar los relojes de 2 computadores. La arquitectura, protocolo y algoritmos de NTP han ido evolucionando durante los últimos 20 años hasta llegar al última versión NTP4 que es la utilizada actualmente.
En las primeras versiones de NTP se podía establecer una precisión de milisegundos, pero actualmente los PC, módems, redes, estaciones de trabajo, etc. son más rápidas por lo que es necesaria una mayor precisión. Por ello en la ultima versión de NTP se proporcionan precisiones de décimas de milisegundos en WANS (redes extensas), y milisegundos en LANS (redes locales) y microsegundos usando como fuente de precisión de tiempo un oscilador de cesio o un receptor GPS.
El protocolo de sincronización determina la diferencia entre la hora del reloj del servidor en relación a la hora del cliente. Bajo petición, el servidor envía un mensaje incluyendo el valor de la hora en ese momento (timestamp), y el cliente almacena esto en su timestamp. Para mayor precisión, el cliente necesita medir el retraso de la propagación desde el servidor al cliente para determinar su offset relativo al servidor. Pero como no es posible determinar el retraso de un camino, a menos que el offset actual sea conocido, el protocolo mide el retraso total en dar toda la vuelta y asume que los tiempos de propagación son estáticamente iguales en cualquier dirección. En general esto es una aproximación útil, sin embargo en Internet hoy en día, las rutas en la red y los retrasos asociados pueden diferir significativamente debido al servicio individual de los proveedores.
1 ENCAPSULADO NTP.
En NTP existen varias capas o Stratums:
Stratum1: En este stratum están los servidores primarios que se sincronizan con hora nacional a través de radio, satélite, y módem.
Stratum2: Aquí aparecen servidores secundarios y clientes se sincronizan con los servidores primarios a través de la subred jerárquica.
A continuación podemos ver un gráfico con un ejemplo de agrupación en distintos stratums
[pic]
Imagen 5.-Protocolo NTP
2 CONFIGURACIONES NTP.
El protocolo NTP puede trabajar en uno o mas modos de trabajo, uno de ellos es el modo cliente/servidor, también llamado maestro/esclavo. En este modo, un cliente se sincroniza con un servidor igual que en el modo RPC convencional.
NTP también soporta un modo simétrico, el cual permite a cada uno de los dos servidores sincronizarse con otro, para proporcionarse copias de seguridad mutuamente.
NTP también soporta el modo broadcast por el cual muchos clientes pueden sincronizarse con uno o varios servidores, reduciendo el tráfico en la red cuando están involucrados un gran número de clientes.
En NTP, el multicast IP también puede ser usado cuando la subred se abarca múltiples redes de trabajo.
La configuración puede ser un serio problema en grandes subredes. Varios esquemas están en bases de datos públicas y servicios de directorios en red que son usados para descubrir servidores. NTP usa el modo broadcast para soportar grandes cantidades de clientes pero para los clientes que solo escuchan es difícil calibrar el retraso y la precisión puede sufrir. En NTP, los clientes determinan el retraso a la vez que buscan un servidor en modo cliente/servidor y luego cambian a modo solo escucha. Además, los clientes NTP pueden hacer un broadcast de un mensaje especial para solicitar respuestas de servidores cercanos y continuar en modo cliente/servidor con los que le respondan.
Aquí tenemos un esquema de las diferentes configuraciones.
[pic]
Imagen 6.- Esquema de Configuraciones
a) Las workstation usan el modo multicast con múltiples servidores de departamento
b) Los servidores de departamento usan modos cliente/servidor con múltiples servidores secundarios (nivel superior en la subred) y modos simétricos los unos con los otros.
c) Los servidores secundarios usan modos cliente/servidor con más de seis servidores primarios externos, modos simétricos con los otros y un servidor NTP secundario externo. (buddy).
Con esto lo que podemos ver es que los servidores de un cierto nivel no solo se comunican con un servidor de capa superior sino también con servidores de su misma capa.
3 ESQUEMA DE SINCRONIZACIÓN
Un servidor NTP primario, o Stratum 1, esta conectado a un reloj de referencia de alta precisión. Esta referencia puede ser, por ejemplo, un reloj atómico, o un receptor de radio o GPS. Además, este servidor cuenta con software para manejar el protocolo NTP.
Otras computadoras, que funcionan como servidores Stratum 2, utilizan un software similar (usualmente el mismo), y consultan automáticamente al servidor primario para sincronizar su reloj. A su vez, estos pueden sincronizar a otros servidores, que en este caso serán Stratum 3, y así podría seguirse hasta 16 niveles. La arquitectura también soporta que un cliente haga sus consultas a mas de un servidor y puede haber comunicaciones entre servidores de un mismo stratum.
Cuanto mas alejado este una computadora del reloj de referencia, o sea, cuanto mas alto sea su Stratum, menos precisa será la sincronización. Sin embargo, cualquier Stratum siempre será suficiente para que el reloj no se aleje más de unos milisegundos de la hora real.
Hasta ahora definimos que una maquina, que llamaremos cliente, puede sincronizarse con otra o con alguna referencia externa, y también puede comportarse como servidor, y utilizarse para sincronizar otras. Siempre que haya una asociación entre dos maquinas, donde una se comporte como cliente, y otra como servidor, al cliente le corresponderá el Stratum inmediatamente superior al del servidor. Hay otra posibilidad, donde dos o mas maquinas se configuran para comportarse entre si como clientes o servidores, según quien este mas cerca de un reloj de referencia, o quien sea mas confiable de acuerdo con el algoritmo que rige la sincronización por NTP. En este tipo de asociaciones, los servidores se llaman Peers.
Para utilizar NTP en una organización, recomendamos instalar un servidor que se sincronice con varias fuentes externas. Este servidor será la única referencia horaria en la organización y todos los equipos estarán sincronizados con el. Opcionalmente, podría instalarse como fuente confiable un receptor GPS.
El servidor NTP instalado servirá para que todos los equipos de la organización lo utilicen para ajustar sus relojes. Este ajuste será de gran importancia ya que permitirá, entre otras, la correlación de eventos entre diferentes equipos.
La elección del equipo y el segmento de red donde se instale el servidor NTP quedan a criterio de la administración de la red. Generalmente, el lugar mas adecuado es la DMZ, o el lugar donde se encuentren los servidores que tienen contacto con el exterior. Sin embargo, como el protocolo NTP utiliza paquetes UDP para sincronizarse, y el cliente es quien envía un paquete para que el servidor responda, se podrá situar el servidor NTP en cualquier punto de la red. Los clientes internos de la red se podrán sincronizar directamente con este servidor. En el caso en que la organización posea gran cantidad de maquinas, o este distribuida en varios sitios remotos, será conveniente la instalación de varios servidores, para que cada uno sirva de sincronizador a un área especifica de cobertura.
[pic]
Imagen 7.- Esquema jerárquico de NTP
2 GPS
El Global Positioning System (GPS) o Sistema de Posicionamiento Global (más conocido con las siglas GPS, aunque su nombre correcto es NAVSTAR-GPS) es un Sistema Global de Navegación por Satélite (GNSS) que permite determinar en todo el mundo la posición de un objeto, una persona, un vehículo o una nave, con una precisión hasta de centímetros, usando GPS diferencial, aunque lo habitual son unos pocos metros. Aunque su invención se atribuye a los gobiernos francés y belga, el sistema fue desarrollado e instalado, y actualmente es operado, por el Departamento de Defensa de los Estados Unidos.
El GPS funciona mediante una red de 27 satélites (24 operativos y 3 de respaldo) en órbita sobre el globo, a 20.200 km, con trayectorias sincronizadas para cubrir toda la superficie de la Tierra. Cuando se desea determinar la posición, el receptor que se utiliza para ello localiza automáticamente como mínimo tres satélites de la red, de los que recibe unas señales indicando la posición y el reloj de cada uno de ellos. Con base en estas señales, el aparato sincroniza el reloj del GPS y calcula el retraso de las señales; es decir, la distancia al satélite. Por "triangulación" calcula la posición en que éste se encuentra. La triangulación en el caso del GPS, consiste en averiguar el ángulo respecto de puntos conocidos, se basa en determinar la distancia de cada satélite respecto al punto de medición. Conocidas las distancias, se determina fácilmente la propia posición relativa respecto a los tres satélites. Conociendo además las coordenadas o posición de cada uno de ellos por la señal que emiten, se obtiene la posición absoluta o coordenada reales del punto de medición. También se consigue una exactitud extrema en el reloj del GPS, similar a la de los relojes atómicos que llevan a bordo cada uno de los satélites.
1 FUNCIONAMIENTO
[pic]
Imagen 8.- Funcionamiento del GPS
El servicio básico de GPS provee una exactitud de aproximadamente 100 metros un 95% de el tiempo Para lograr esto, cada uno de los 24 satélites emite una señal a los receptores en tierra. GPS determina la localización al computar la diferencia entre el tiempo en que una señal es enviada y el tiempo en que es recibida. Los satélites GPS llevan consigo relojes atómicos que proveen información precisa en cuanto al tiempo. Una "estampilla de tiempo" (Esto es, el tiempo en que se envío el mensaje desde orbita) es incluida en los mensajes de GPS para que los receptores sepan cuando se envío la señal. La señal también contiene datos que permiten a los receptores saber la localización de los satélites y para hacer otros ajustes necesarios para una mejor localización. El receptor usa la diferencia en tiempo entre la recepción de la señal y su envío para computar la distancia (o rango) entre el receptor y el satélite. El receptor debe de tomar en cuenta los retrasos por propagación o el retardo de la señal causada por la ionosfera y la troposfera. Con la información de los rangos de tres satélites y la información de la posición de un satélite cuando la señal fue enviada el receptor puede computar su propia posición tridimensional. Un reloj atómico sincronizado al GPS es necesario para poder computar los rangos de las tres señales. Sin embargo, al tomar esta medida de tiempo de un cuarto satélite, el receptor se evita la necesidad de un reloj atómico. Así que el receptor utiliza cuatro satélites para computar latitud, longitud, altura y tiempo.
2 TRIANGULACIÓN
Para ubicar la posición exacta donde nos encontramos situados, el receptor GPS tiene que localizar por lo menos 3 satélites que le sirvan de puntos de referencia. En realidad eso no constituye ningún problema porque normalmente siempre hay 8 satélites dentro del “campo visual” de cualquier receptor GPS. Para determinar el lugar exacto de la órbita donde deben encontrarse los satélites en un momento dado, el receptor tiene en su memoria un almanaque electrónico que contiene esos datos.
Tanto los receptores GPS de mano, como los instalados en vehículos con antena exterior fija, necesitan abarcar el campo visual de los satélites. Generalmente esos dispositivos no funcionan bajo techo ni debajo de las copas de los árboles, por lo que para que trabajen con precisión hay que situarlos en el exterior, preferiblemente donde no existan obstáculos que impidan la visibilidad y reduzcan su capacidad de captar las señales que envían a la Tierra los satélites.
[pic]
Imagen 9.- Triangulación de los Satelites
El principio de funcionamiento de los receptores GPS es el siguiente:
Primero: cuando el receptor detecta el primer satélite se genera una esfera virtual o imaginaria, cuyo centro es el propio satélite. El radio de la esfera, es decir, la distancia que existe desde su centro hasta la superficie, será la misma que separa al satélite del receptor. Éste último asume entonces que se encuentra situado en un punto cualquiera de la superficie de la esfera, que aún no puede precisar.
[pic]
Imagen 10.- Triangulación del primer Satélite
Segundo: al calcular la distancia hasta un segundo satélite, se genera otra esfera virtual. La esfera anteriormente creada se superpone a esta otra y se crea un anillo imaginario que pasa por los dos puntos donde se interceptan ambas esferas. En ese instante ya el receptor reconoce que sólo se puede encontrar situado en uno de ellos.
[pic]
Imagen 11.- Triangulación con el segundo Satélite
Tercero: el receptor calcula la distancia a un tercer satélite y se genera una tercera esfera virtual. Esa esfera se corta con un extremo del anillo anteriormente creado en un punto en el espacio y con el otro extremo en la superficie de la Tierra. El receptor discrimina como ubicación el punto situado en el espacio utilizando sus recursos matemáticos de posicionamiento y toma como posición correcta el punto situado en la Tierra.
[pic]
Imagen 12.- Triangulación con el tercer Satélite
Cuarto: una vez que el receptor ejecuta los tres pasos anteriores ya puede mostrar en su pantalla los valores correspondientes a las coordenadas de su posición, es decir, la latitud y la longitud.
Quinto: para detectar también la altura a la que se encuentra situado el receptor GPS sobre el nivel del mar, tendrá que medir adicionalmente la distancia que lo separa de un cuarto satélite y generar otra esfera virtual que permitirá determinar esa medición.
Si por cualquier motivo el receptor falla y no realiza las mediciones de distancias hasta los satélites de forma correcta, las esferas no se interceptan y en ese caso no podrá determinar, ni la posición, ni la altura.
3 MEDICION DE LAS DISTACIAS DE LOS SATELITES.
Desde el mismo momento que el receptor GPS detecta una señal de radiofrecuencia transmitida por un satélite desde su órbita, se genera una esfera virtual o imaginaria que envuelve al satélite. El propio satélite actuará como centro de la esfera cuya superficie se extenderá hasta el punto o lugar donde se encuentre situada la antena del receptor; por tanto, el radio de la esfera será igual a la distancia que separa al satélite del receptor. A partir de ese instante el receptor GPS medirá las distancias que lo separan como mínimo de dos satélites más. Para ello tendrá que calcular el tiempo que demora cada señal en viajar desde los satélites hasta el punto donde éste se encuentra situado y realizar los correspondientes cálculos matemáticos.
Todas las señales de radiofrecuencias están formadas por ondas electromagnéticas que se desplazan por el espacio de forma concéntrica a partir de la antena transmisora, de forma similar a como lo hacen las ondas que se generan en la superficie del agua cuando tiramos una piedra. Debido a esa propiedad las señales de radio se pueden captar desde cualquier punto situado alrededor de una antena transmisora. Las ondas de radio viajan a la velocidad de la luz, es decir, 300 mil kilómetros por segundo (186 mil millas por segundo) medida en el vacío, por lo que es posible calcular la distancia existente entre un transmisor y un receptor si se conoce el tiempo que demora la señal en viajar desde un punto hasta el otro.
Para medir el momento a partir del cual el satélite emite la señal y el receptor GPS la recibe, es necesario que tanto el reloj del satélite como el del receptor estén perfectamente sincronizados. El satélite utiliza un reloj atómico de cesio, extremadamente exacto, pero el receptor GPS posee uno normal de cuarzo, no tan preciso. Para sincronizar con exactitud el
reloj del receptor GPS, el satélite emite cada cierto tiempo una señal digital o patrón de control junto con la señal de radiofrecuencia. Esa señal de control llega siempre al receptor GPS con más retraso que la señal normal de radiofrecuencia. El retraso entre ambas señales será igual al tiempo que demora la señal de radiofrecuencia en viajar del satélite al receptor GPS.
La distancia existente entre cada satélite y el receptor GPS la calcula el propio receptor realizando diferentes operaciones matemáticas. Para hacer este cálculo el receptor GPS multiplica el tiempo de retraso de la señal de control por el valor de la velocidad de la luz. Si la señal ha viajado en línea recta, sin que la haya afectado ninguna interferencia por el camino, el resultado matemático será la distancia exacta que separa al receptor del satélite.
Las ondas de radio que recorren la Tierra lógicamente no viajan por el vacío sino que se desplazan a través de la masa gaseosa que compone la atmósfera; por tanto, su velocidad no será exactamente igual a la de la luz, sino un poco más lenta. Existen también otros factores que pueden influir también algo en el desplazamiento de la señal, como son las condiciones atmosféricas locales, el ángulo existente entre el satélite y el receptor GPS, etc. Para corregir los efectos de todas esas variables, el receptor se sirve de complejos modelos matemáticos que guarda en su memoria. Los resultados de los cálculos los complementa después con la información adicional que recibe también del satélite, lo que permite mostrar la posición con mayor exactitud.
4 APLICACIONES DEL GPS
Ya hemos visto cómo funciona el GPS y cuál es su función principal: conocer nuestra posición.
Aunque conocer nuestra posición pueda parecer algo trivial, cada vez más se está convirtiendo en un aspecto casi imprescindible en muchos campos, ya sean profesionales o lúdicos. A grandes rasgos, podemos dividir los campos de aplicación en cinco.
Posicionamiento: la aplicación más obvia del GPS es la de determinar una posición o localización. El GPS es el primer sistema que permite determinar con un error mínimo nuestra posición en cualquier lugar del planeta y bajo cualquier circunstancia.
Navegación: dado que podemos calcular posiciones en cualquier momento y de manera repetida, conocidos dos puntos podemos determinar un recorrido o, a partir de dos puntos conocidos, determinar la mejor ruta entre ellos dos.
Seguimiento: mediante la adaptación del GPS a sistemas de comunicación, un vehículo o persona puede comunicar su posición a una central de seguimiento.
Topografía: gracias a la precisión del sistema, los topógrafos cuentan con una herramienta muy útil para la determinación de puntos de referencia, accidentes geográficos o infraestructuras, entre otros, lo que permite disponer de información topográfica precisa, sin errores y fácilmente actualizable.
Sincronización: dada la característica adicional de medición del tiempo de que disponen los receptores GPS, podemos emplear este sistema para determinar momentos en los que suceden o sucederán determinados eventos, sincronizarlos, unificar horarios...
3 HUSOS HORARIOS
Geográficamente los husos horarios son cada una de las veinticuatro áreas en que se divide la Tierra y que siguen la misma definición de tiempo cronométrico. Se llaman así porque tienen forma de huso de hilar o de gajo de naranja y están centrados en meridianos de una longitud que es múltiplo de 15°. Anteriormente, la gente usaba el tiempo solar aparente, con lo que la hora se diferenciaba ligeramente de una ciudad a otra si no se encontraban sobre un mismo meridiano. El empleo de los husos horarios corrigió el problema parcialmente, al sincronizar los relojes de una región al mismo tiempo solar medio.
Actualmente la definición de huso horario se basa en las fronteras de países y regiones, y sus límites pueden ser bastante irregulares. En este sentido a veces se usa la frase zona horaria.
[pic]
Imagen 13.- Husos Horarios
Todos los husos horarios se definen en relación al Tiempo Universal Coordinado (UTC), el huso horario centrado sobre el meridiano de Greenwich que, por tanto, contiene a Londres.
Puesto que la Tierra gira de Oeste a Este, al pasar de un huso horario a otro en dirección Este hay que sumar una hora. Por el contrario, al pasar de Este a Oeste hay que restar una hora. El meridiano de 180°, conocido como línea internacional de cambio de fecha, marca el cambio de día.
Los países indicados con (N) o (S) utilizan horario de verano (hora para aprovechar la luz solar): agregan una hora en verano. Los indicados con (N) pertenecen al hemisferio norte y, por lo
tanto, esa hora la agregan en marzo o abril. Los indicados con (S) pertenecen al hemisferio sur, y agregan una hora en octubre o noviembre. La lista de territorios se ordena de norte a sur.
1 HUSOS HORARIOS DE MÉXICO.
Los Usos horarios de México son regulados por el Centro Nacional de Metrología, entidad gubernamental dependiente de la Secretaría de Economía. Según lo establecido por esta dependencia, a México le corresponden 3 husos horarios al oeste del meridiano de Greenwich o Tiempo Universal Coordinado, por lo que sus horas se restan al de éste; estos usos horarios son: UTC -8, UTC -7 y UTC -6.
Para su vigencia en México, estos husos horarios reciben nombres particulares, que son:
□ UTC -8: Tiempo del Pacífico oficialmente llamada Zona Noroeste
□ UTC -7: Tiempo de la Montaña oficialmente llamada Zona Pacífico
□ UTC -6: Tiempo del Centro oficialmente llamada Zona Centro
Los límites de cada uno de ellos son fijados siguiendo las fronteras físicas entre los estados o en algunos casos entre municipios de un estado, por lo que en el estricto sentido no siguen el límite exacto de los husos horarios.
A diferencia de otros países con igual o mayor cantidad de horarios, México no tiene una cultura de diferenciación de ellos, debido en gran parte a la centralización de la vida nacional en la Ciudad de México, a la que le corresponde, junto con más de la mitad del país, el Tiempo del Centro, siendo por ejemplo que las cadenas nacionales de televisión solo contemplen el horario del centro al anunciar sus programaciones. Entre otras razones esto conlleva a que solo tengan verdadera constancia de las diferencias de horario quienes viven en los dos husos diferentes al del centro, mientras que la gran mayoría de la población que habita este horario no está consciente de la existencia de otros
[pic]
Imagen 14.- Husos Horarios en México
4 TIEMPO SIDERAL
El tiempo sidéreo, también denominado tiempo sideral, es el tiempo medido por el movimiento diurno aparente del equinoccio vernal, que se aproxima, aunque sin ser idéntico, al movimiento de las estrellas. Se diferencia en la presesión del equinoccio vernal con respecto a las estrellas.
De forma más precisa, el tiempo sidéreo se define como el ángulo horario del equinoccio vernal. Cuando el equinoccio vernal culmina en el meridiano local, el tiempo sidéreo local es 00.00.
[pic]
Imagen 15.- Tiempo Sideral
5 COMUNICACIÓN SERIAL.
1 DEFINICION.
La comunicación serial es un protocolo muy común para comunicación entre dispositivos que se incluye de manera estándar en prácticamente cualquier computadora. La mayoría de las computadoras incluyen dos puertos seriales RS-232. La comunicación serial es también un protocolo común utilizado por varios dispositivos para instrumentación. Además, la comunicación serial puede ser utilizada para adquisición de datos si se usa en conjunto con un dispositivo remoto de muestreo.
El concepto de comunicación serial es sencillo. El puerto serial envía y recibe bytes de información un bit a la vez. Aun y cuando esto es más lento que la comunicación en paralelo, que permite la transmisión de un byte completo por vez, este método de comunicación es más sencillo y puede alcanzar mayores distancias. Por ejemplo, la especificación IEEE 488 para la comunicación en paralelo determina que el largo del cable para el equipo no puede ser mayor a 20 metros, con no más de 2 metros entre cualesquier dos dispositivos; por el otro lado, utilizando comunicación serial el largo del cable puede llegar a los 1200 metros.
Típicamente, la comunicación serial se utiliza para transmitir datos en formato ASCII. Para realizar la comunicación se utilizan 3 líneas de transmisión: (1) Tierra (o referencia), (2) Transmitir, (3) Recibir. Las características más importantes de la comunicación serial son la
velocidad de transmisión, los bits de datos, los bits de parada, y la paridad. Para que dos puertos se puedan comunicar, es necesario que las características sean iguales.
[pic]
Imagen 16.- Modo de comunicación en serie
□ Mucho menos costoso
Número reducido de líneas
□ Menor disposición a errores
□ Los datos necesitan ser serializados/deserializados
□ Se requiere un protocolo de transmisión
2 MODOS DE TRANSMISIÓN
Un método de caracterizar líneas, dispositivos terminales, computadoras y modems es por su modo de transmisión o de comunicación. Las tres clases de modos de transmisión son simplex, half-duplex y full-duplex.
1 TRANSMISIÓN SIMPLEX
La transmisión simplex (sx) o unidireccional es aquella que ocurre en una dirección solamente, deshabilitando al receptor de responder al transmisor. Normalmente la transmisión simplex no se utiliza donde se requiere interacción humano-máquina. Ejemplos de transmisión simplex son: La radiodifusión (broadcast) de TV y radio, etc.
[pic]
Imagen 17.- Transmisión Simplex
2 TRANSMISIÓN HALF-DUPLEX
La transmisión half-duplex (hdx) permite transmitir en ambas direcciones; sin embargo, la transmisión puede ocurrir solamente en una dirección a la vez. Tanto transmisor y receptor comparten una sola frecuencia. Un ejemplo típico de half-duplex es el radio de banda civil (CB) donde el operador puede transmitir o recibir, pero no puede realizar ambas funciones simultáneamente por el mismo canal. Cuando el operador ha completado la transmisión, la otra parte debe ser avisada que puede empezar a transmitir.
[pic]
Imagen 18.- Transmisión Half-Duplex
3 TRANSMISIÓN FULL-DUPLEX
La transmisión full-duplex (fdx) permite transmitir en ambas direcciones, pero simultáneamente por el mismo canal. Existen dos frecuencias una para transmitir y otra para recibir. Ejemplos de este tipo abundan en el terreno de las telecomunicaciones, el caso más típico es la telefonía, donde el transmisor y el receptor se comunican simultáneamente utilizando el mismo canal, pero usando dos frecuencias.
[pic]
Imagen 19.- Transmisión Full-Duplex
3 COMUNICACIÓN ASINCRONA
Cuando se opera en modo asíncrono no existe una línea de reloj común que establezca la duración de un bit y el carácter puede ser enviado en cualquier momento. Esto conlleva que cada dispositivo tiene su propio reloj y que previamente se ha acordado que ambos dispositivos transmitirán datos a la misma velocidad.
No obstante, en un sistema digital, un reloj es normalmente utilizado para sincronizar la transferencia de datos entre las diferentes partes del sistema. El reloj definirá el inicio y fin de cada unidad de información así como la velocidad de transmisión. Si no existe reloj común, algún modo debe ser utilizado para sincronizar el mensaje.
En realidad, la frecuencia con que el reloj muestrea la línea de comunicación es mucho mayor que la cadencia con que llegan los datos. Por ejemplo, si los datos están llegando a una cadencia de 2400 bps, el reloj examinará la línea unas 19200 veces por segundo, es decir, ocho veces la cadencia binaria. La gran rapidez con que el reloj muestrea la línea, permite al dispositivo receptor detectar una transmisión de 1 a 0 o de 0 a 1 muy rápidamente, y mantener así la mejor sincronización entre los dispositivos emisor y receptor.
El tiempo por bit en una línea en que se transfiere la información a 2400 bps es de unos 416 microsegundos (1 seg/2400). Una frecuencia de muestreo de 2400 veces por segundo nos permitirá muestrear el principio o el final del bit. En ambos casos detectaremos el bit, sin embargo, no es extraño que la señal cambie ligeramente, y permanezca la línea con una duración un poco más larga o más corta de lo normal. Por todo ello, una frecuencia de muestreo lenta no sería capaz de detectar el cambio de estado de la señal a su debido tiempo, y esto daría lugar a que la estación terminal no recibiera los bits correctamente.
[pic]
Imagen 20.- Modo de comunicación Asincrono
1 BIT DE INICIO Y BIT DE PARO.
En la transmisión asíncrona un carácter a transmitir es encuadrado con un indicador de inicio y fin de carácter, de la misma forma que se separa una palabra con una letra mayúscula y un espacio en una oración. La forma estándar de encuadrar un carácter es a través de un bit de inicio y un bit de parada.
Durante el intervalo de tiempo en que no son transferidos caracteres, el canal debe poseer un "1" lógico. Al bit de parada se le asigna también un "1". Al bit de inicio del carácter a transmitir se le asigna un "0". Por todo lo anterior, un cambio de nivel de "1" a "0" lógico le indicará al receptor que un nuevo carácter será transmitido.
[pic]
Imagen 21.- Formato de Transmisión Asíncrona
2 REGLAS DE TRANSMISIÓN ASINCRONA
La transmisión asíncrona que vamos a ver es la definida por la norma RS232, y que se basa en las siguientes reglas:
a) Cuando no se envían datos por la línea, ésta se mantiene en estado alto (1).
b) Cuando se desea transmitir un carácter, se envía primero un bit de inicio que pone la línea a estado bajo (0) durante el tiempo de un bit.
c) Durante la transmisión, si la línea está a nivel bajo, se envía un 0 y si está a nivel alto se envía un 1.
d) A continuación se envían todos los bits del mensaje a transmitir con los intervalos que marca el reloj de transmisión. Por convenio se transmiten entre 5 y 8 bits.
e) Se envía primero el bit menos significativo, siendo el más significativo el último en enviarse.
f) A continuación del último bit del mensaje se envía el bit (o los bits) del final que hace que la línea se ponga a 1 por lo menos durante el tiempo mínimo de un bit. Estos bits pueden ser un bit de paridad para detectar errores y el bit o bits de stop, que indican el fin de la transmisión de un carácter.
Los datos codificados por esta regla, pueden ser recibidos siguiendo los pasos siguientes:
a) Esperar la transición 1 a 0 en la señal recibida.
b) Activar el reloj con una frecuencia igual a la del transmisor.
c) Muestrear la señal recibida al ritmo de ese reloj para formar el mensaje.
d) Leer un bit más de la línea y comprobar si es 1 para confirmar que no ha habido error en la sincronización.
4 VELOCIDAD DE TRANSMISIÓN
En la transmisión asíncrona por cada caracter se envía al menos 1 bit de inicio y 1 bit de parada así como opcionalmente 1 bit de paridad. Esta es la razón de que los baudios no se correspondan con el número de bits de datos que son transmitidos.
[pic]
Imagen 22.- Formato básico de Transmisión asíncrona
Ejemplo:
Determinar cuántos bits de datos y caracteres son transmitidos de manera asíncrona en 1 segundo si se transmite a una velocidad de 2400 baudios con 1 bit de inicio, 2 bits de parada, 1 bit de paridad y 6 bits de datos por caracter:
Para transmitir un caracter se necesitará:
1 bit inicio + 6 bits datos + 1 bit paridad + 2 bits parada =10 bits.
Como la velocidad de transmisión es 2400 baudios y cada caracter consume 10 bits, se transmitirán 240 caracteres por segundo (2400/10). Como cada caracter posee 6 bits de datos serán transmitidos 240 * 6 = 1440 bits de datos por segundo.
La característica fundamental del formato de transmisión asíncrono es su capacidad de manejar datos en tiempo real, con un intervalo de longitud arbitraria entre caracteres sucesivos. Al final de cada caracter, la línea va a 1 en el bit de parada y permanece en ese estado durante un número arbitrario de bits ociosos. El inicio del nuevo caracter estará definido por la transición a 0 del bit de inicio.
[pic]
Imagen 23.- Transmisión asíncrona con velocidad menor que la máxima posible
En la siguiente figura se muestra la mayor velocidad asíncrona posible con el bit de paridad.
[pic]
Imagen 24.- Transmisión asíncrona con la velocidad máxima posible
5 TRANSMISIÓN SINCRONA
Es un método más eficiente de comunicación en cuanto a velocidad de transmisión. Ello viene dado porque no existe ningún tipo de información adicional entre los caracteres a ser transmitidos.
[pic]
Imagen 25.- Transmisión sincrónica
Cuando se transmite de manera síncrona lo primero que se envía es un octeto de sincronismo ("sync"). El octeto de sincronismo realiza la misma función que el bit de inicio en la transmisión asíncrona, indicando al receptor que va ha ser enviado un mensaje. Este carater, además, utiliza la señal local de reloj para determinar cuándo y con qué frecuencia será muestreada la señal, es decir, permite sincronizar los relojes de los dispositivos transmisor y receptor. La mayoría de los dispositivos de comunicación llevan a cabo una resincronización contra posibles desviaciones del reloj, cada uno o dos segundos, insertando para ello caracteres del tipo "sync" periódicamente dentro del mensaje.
Los carácteres de sincronismo deben diferenciarse de los datos del usuario para permitir al receptor detectar los caracteres "sync". Por ejemplo, el código ASCII utiliza el octeto 10010110.
Existen ocasiones en que son definidos dos caracteres de sincronismo, ello puede ser necesario si, por cualquier motivo el carácter "sync" original se desvirtuara, el siguiente permitirá la reinicialización del receptor. En segundo lugar, puede ocurrir que el equipo receptor necesite un tiempo adicional para adaptarse a la señal entrante.
Cuando se transmite de forma síncrona, es necesario mantener el sincronismo entre el transmisor y el receptor cuando no se envían caracteres, para ello son insertados caracteres de sincronismo de manera automática por el dispositivo que realiza la comunicación.
[pic]
Imagen 26.- Inserción automática de caracteres de sincronismo
El receptor/transmisor síncrono debe indicar además cuándo el sincronismo ha sido logrado por parte del receptor.
6 DETECTAR ERRORES EN LA COMUNICACIÓN.
Cuando se escriben o se envían datos, pueden producirse errores, entre otras cosas, por ruidos inducidos en las líneas de transmisión de datos. Es por tanto necesario comprobar la integridad de los datos transmitidos mediante algún método que permita determina si se ha producido un error.
En un caso típico, si al transmitirse un mensaje se determina que se ha producido un error, el receptor solicita de nuevo el mensaje al emisor.
Se pueden detectar errores de acuerdo a la forma de transmisión:
Transmisión asíncrona:
□ Paridad.
□ Sobre escritura.
□ Error de encuadre (framing).
Transmisión síncrona:
□ Paridad.
□ Sobre escritura.
7 GENERADORES Y DETECTORES DE PARIDAD
Como un error en una transmisión serie solamente suele afectar a un bit, uno de los métodos más comunes para detectar errores es el control de la paridad.
El control de paridad consiste en añadir un bit, denominado de paridad, a los datos que se envían o escriben.
[pic]
Imagen 27.- Detector de paridad
La paridad puede ser par o impar.
1 PARIDAD PAR
El bit de paridad será cero, cuando el número de bit "unos" que contienen los datos a transmitir sea un número par, y el bit de paridad será uno cuando los datos que se mandan contienen un número impar de unos.
[pic]
Tabla 2.- Paridad par
La suma de los bits que son unos, contando datos y bit de paridad dará siempre como resultado un número par de unos.
En las siguientes figuras se muestra como se puede realizar un generador de paridad y un detector de paridad con puertas lógicas or-exclusivas (EXOR).
[pic]
Imagen 288.- Generador de Paridad
[pic]
Imagen 29.- Detector de Paridad
2 PARIDAD IMPAR
[pic]
Tabla 3.- Paridad impar
En el sistema de paridad impar, el número de unos (datos + paridad) siempre debe ser impar.
Ejemplo:
Se quieren transmitir los datos C3H y 43H con paridad impar.
□ C3H = 1100 0011
□ 43H = 0100 0011
C3H tiene un número par de unos, por lo que el bit de paridad a insertar debe ser 1 para que se cumpla que el número de unos (datos + paridad) siempre debe ser impar:
[pic]
Imagen 29.- Ejemplo de Paridad Impar
43H tiene un número impar de unos, por lo que el bit de paridad a insertar debe ser 0 para que se cumpla que el número de unos (datos + paridad) siempre debe ser impar:
[pic]
Imagen 30.- Ejemplo de paridad Impar
La secuencia de transmisión se muestra en la figura siguiente.
[pic]
Imagen 31.- Secuencias de transmisión Impar
Supongamos que se comete un error en la recepción de 43H en la posición más significativa (D7). Esto significa que se ha recibido el carácter C3H (bit MSB complementado), el receptor discrimina este error al recibir un número par de unos (bit D0, D1, D6, D7 y paridad):
[pic]
Imagen 32.-Ejemplo de error de recepción en paridad impar
Como fue definida paridad impar, se detecta el error pues debería haber un número impar de unos y hay cuatro. Como respuesta a la detección el sistema podría solicitar la transmisión de este carácter nuevamente.
Por último, y considerando lo anterior, indicar que el método de detección de errores mediante paridad sólo es válido cuando falla un bit, si por ejemplo fallan dos, no se detectará el error.
3 METODO CHECKSUM
Puede existir el caso en que, por ejemplo, se alteren dos bits en un caracter transmitido y si se ha implementado la comprobación de paridad, el error no será detectado.
Existen otros métodos de detección de errores como son la comprobación de redundancia cíclica (CRC) y la comprobación de suma (checksum). Por su simplicidad, será abordado el método checksum.
El método checksum puede ser utilizado tanto en la transmisión síncrona como en la asíncrona. Se basa en la transmisión, al final del mensaje, de un byte (o bytes) cuyo valor sea el complemento a dos de la suma de todos los carácteres que han sido transmitidos en el mensaje. El receptor implementará una rutina que suma todos los bytes de datos recibidos y al resultado se le sumará el último byte (que posee la información en complemento a dos de la suma de los caracteres transmitidos) y si la recepción del mensaje ha sido correcta, el resultado debe ser cero.
Ejemplo:
Indicar el último caracter a transmitir cuando se implementa el método de checksum. Los datos a transmitir serán 40H, 35H y 0EH.
Se realiza la suma:
40H + 35H + 0EH = 83H
Ahora se determina el complemento a dos del resultado:
83H = 1000 0011
0111 1100
+ 1
-------------
0111 1101 = 7DH
El último carácter a transmitir será 7DH.
8 INTERFAZ RS232
RS-232 (también conocido como Electronic Industries Alliance RS-232C) es una interfaz que designa una norma para el intercambio serie de datos binarios entre un DTE (Equipo terminal de datos) y un DCE (Data Communication Equipment, Equipo de Comunicación de datos), aunque existen otras situaciones en las que también se utiliza la interfaz RS-232.
En particular, existen ocasiones en que interesa conectar otro tipo de equipamientos, como pueden ser computadores. Evidentemente, en el caso de interconexión entre los mismos, se requerirá la conexión de un DTE (Data Terminal Equipment) con otro DTE.
El RS-232 consiste en un conector tipo DB-25 (de 25 pines), aunque es normal encontrar la versión de 9 pines (DB-9), más barato e incluso más extendido para cierto tipo de periféricos (como el ratón serie del PC).
[pic]
Imagen 33.- Conectores hembra y macho para el protocolo RS232
En la siguiente tabla se muestran las señales RS-232 más comunes según los pines asignados:
[pic]
Tabla 4.- Señales RS-232 más comunes
1 CONSTRUCCION FISICA
La interfaz RS-232 está diseñada para distancias cortas, de unos 15 metros o menos, y para velocidades de comunicación bajas, de no más de 20 [Kb/s]. A pesar de ello, muchas veces se utiliza a mayores velocidades con un resultado aceptable. La interfaz puede trabajar en comunicación asíncrona o síncrona y tipos de canal simplex, half duplex o full duplex. En un canal simplex los datos siempre viajarán en una dirección, por ejemplo desde DCE a DTE. En un canal half duplex, los datos pueden viajar en una u otra dirección, pero sólo durante un determinado periodo de tiempo; luego la línea debe ser conmutada antes que los datos puedan viajar en la otra dirección. En un canal full duplex, los datos pueden viajar en ambos sentidos simultáneamente. Las líneas de handshaking de la RS-232 se usan para resolver los problemas asociados con este modo de operación, tal como en qué dirección los datos deben viajar en un instante determinado.
Si un dispositivo de los que están conectados a una interfaz RS-232 procesa los datos a una velocidad menor de la que los recibe deben de conectarse las líneas handshaking que permiten realizar un control de flujo tal que al dispositivo más lento le de tiempo de procesar la información. Las líneas de "hand shaking" que permiten hacer este control de flujo son las líneas RTS y CTS. Los diseñadores del estándar no concibieron estas líneas para que funcionen de este modo, pero dada su utilidad en cada interfaz posterior se incluye este modo de uso.
La interfaz RS232 resuelve tres aspectos en la comunicación que se establece entre el DTE, Equipo Terminal de Datos, por ejemplo un PC y el DCE, Equipo para la comunicación de datos, por ejemplo un ratón:
Características eléctricas de la señal: Se establece que la longitud máxima entre el DTE y el DCE no debe ser superior a los 15 metros y la velocidad máxima de transmisión es de 20.000 bps. Los niveles lógicos no son compatibles TTL, considerando:
1 lógico entre -3V y -15V
0 lógico entre +3V y +15V
Características mecánicas de los conectores: Se utiliza un conector 25 patillas, DB 25, o de 9 patillas, DB 9, donde el conector macho identifica al DTE y el conector hembra al DCE.
Descripción funcional de las señales usadas: Las señales están básicamente divididas en dos grupos:
Señales primarias, que son normalmente utilizadas para las transferencias de datos
Señales secundarias, utilizadas para el control de la información que será transferida.
La interfaz RS232 está definida tanto para la transmisión síncrona como para la asíncrona, pero cuando se utiliza esta última, sólo un conjunto de terminales (de los 25), es utilizado.
2 VELOCIDAD
La velocidad está estandarizada según la norma RS 232C en baudios:
□ 75
□ 110
□ 150
□ 300
□ 600
□ 1200
□ 2400
□ 4800
□ 9600
□ 19200
3 CONECTORES
DB25 patillas macho y hembra:
[pic]
Imagen 34.- Conector macho y hembra DB9
DB9 patillas4 macho y hembra
[pic]
Imagen 35.- Vista real de un conector DB9 macho
Ambos conectores son totalmente compatibles entre sí y existen adaptadores para pasar de un conector a otro
4 DESCRIPCION DE TERMINALES.
Para ilustrar mejor el significado de cada terminal, consideremos a modo de ejemplo que el DTE podría ser un PC y el DCE un ratón. Se considerará el terminal DB25. Más adelante, en RS232 en el PC se volverá al tema de los conectores.
[pic]
Imagen 36.- Numeración de pines
□ TXD (Transmit Data, transmisión de datos, salida, pat. 2): Señales de datos que se transmiten del DTE al DCE. En principio, los datos no se pueden transmitir si alguno de los terminales RTS, CTS, DSR ó DTR está desactivado.
□ RXD (Receive Data, recepción de datos, entrada, pat. 3): Señales de datos transmitidos desde el DCE al DTE.
□ DTR (Data Terminal Ready, terminal de datos preparado, salida, pat. 20): Señal del DTE que indica que está conectado, generalmente en "0" indica que el DTE está listo para transmitir o recibir.
□ DSR (Data Set Ready, dispositivo preparado, entrada, pat. 6): Señal del DCE que indica que el dispositivo está en modo de transmisión de datos.
□ RTS (Request To Send, petición de envío, salida, pat. 4): Señal del DTE al DCE, notifica al DCE que el DTE dispone de datos para enviar. Se emplea en líneas semiduplex para controlar la dirección de transmisión. Una transición de 1 a 0 avisa al DCE que tome las medidas necesarias para prepararse para la transmisión.
□ CTS (Clear To Send, preparado para transmitir, entrada, pat. 5): Señal del DCE al DTE indicando que puede transmitirle datos.
□ CD (Carrier Detect, detección de portadora, entrada, pat. 8): Señal del DCE que ha detectado la señal portadora enviado por un modem remoto o que la línea telefónica está abierta.
□ RI (Ring Indicator, timbre o indicador de llamada entrante, entrada, pat. 22): Señal del DCE indicando que está recibiendo una llamada por un canal conmutado.
□ SG (GND) (System Ground ó Signal Ground, masa de señal, pat. 7): Masa común para todos las líneas.
□ FG (GND) (Shield ó Protective Ground, tierra de protección, pat. 1): El conductor esta eléctricamente conectado al equipo.
Una secuencia normal, a través de la RS232, es la siguiente:
□ Ambos dispositivos son alimentados, indicando encendido (si ha sido establecido en el equipo). El DTE activa el terminal DTR y el DCE activa el terminal DSR. Una interfase RS232 bien diseñada no comunicará hasta que estos dos terminales estén activos. El DTE esperará la activación del terminal DSR y el DTE la activación del terminal DTR. Aunque DTR y DSR algunas veces pueden ser utilizados para el control del flujo, estos terminales solo indican que los dispositivos están conectados.
□ El DTE pregunta al DCE si este está listo. El DTE activa la línea RTS. El DCE si está listo, responde activando la línea CTS. Puestos de acuerdo ambos equipos, se puede entrar a comunicar.
□ Los datos son transferidos en ambos sentidos. El DTE envía información al DCE a través del terminal TXD. El DCE envía información al DTE a través del terminal RXD.
CAPITULO III DESARROLLO DEL PROTOTIPO
Debido a las actividades que se realizan en la empresa de Radiotelevisión de Veracruz, como lo son las transmisiones de programas el como se deben de organizar para el reparto de actividades dentro de los foros y a la manera en que se requieren coordinar las actividades de cada una de las personas encargadas, es muy importante que todos compartan el mismo horario, y que no sean distintas la hora de un foro con respecto de otro.
Un ejemplo de esto es cuando se va a empezar a transmitir un programa en vivo participan tres diferentes foros, como los son el foro donde se graba, el de audio y el transmisión, los cuales deben estar coordinados, para empezar cada uno en los tiempos que les corresponden.
Debido a todo esto surge la necesidad de realizar un dispositivo llamado MASTER que se capaz de sincronizarse con otros dispositivos llamados SLAVE para mantener en perfecta sincronía las actividades de cada uno de los foros cuando se requiera.
El desarrollo del prototipo “De un sistema de sincronización Distribuido” consta de varias fases, como lo son: la interacción entre la PC y el dispositivo electrónico, la adquisición de hora por medio de la computadora, la transmisión de datos en protocolo RS232, y la sincronización entre todos los dispositivos electrónicos, los cuales se explicaran a continuación con los respectivos elementos que se utilizaron la realización del prototipo.
1 VISUAL BASIC
Una de las herramientas que se empleo para el desarrollo del prototipo es la utilización de visual Basic, que es uno de los tantos lenguajes de programación existentes hoy en día. Visual Basic Es un lenguaje de programación que se ha diseñado para facilitar el desarrollo de aplicaciones en un entorno grafico (GUI-GRAPHICAL USER INTERFACE) Como Windows 98, Windows NT o superior.
[pic]
Imagen 37.- Vista inicial de Visual Basic
Una de las características de Visual Basic es de que es un diseñador de entorno de datos, lo cual significa que es posible generar, de manera automática, conectividad entre controles y datos mediante la acción de arrastrar y colocar sobre formularios o informes.
La primera etapa del desarrollo del prototipo consta de la elaboración de un programa en Visual Basic que sea capaz de extraer la hora de la computadora del usuario y mostrarlo en pantalla, así como también de mandar esta información extraída através del puerto serial de la computadora hacia el dispositivo electrónico que actúa como Master.
En el siguiente Diagrama de Flujo se explica el funcionamiento del programa elaborado.
[pic]
Imagen 38.- Diagrama de flujo del funcionamiento del programa en Visual Basic
Al ejecutarse como primera acción que debe de hacer el programa, es extraer la hora actual de la computadora en donde se esta instalado, una vez hecho esto el programa tiende a guardar la hora adquirida en diferentes variables.
Se ocuparon tres diferentes variables para que en cada una se almacenaran los datos obtenidos de la hora exacta de la computadora como lo son, horas, minutos y segundos, para que después pueda desplegarse en la pantalla de la computadora la hora actual del sistema tal y como se muestra en la siguiente imagen.
[pic]
Imagen 39.- Vista del reloj digital programado en Visual Basic
Una vez hecho el despliegue en pantalla de la hora actual del sistema, el programa internamente hace por código programado, la revisión de si es esta la primera vez, o no en que se ejecuta el programa, esto se realiza con motivo de que si es la primera vez automáticamente empiece la transmisión de los datos obtenidos por el protocolo de comunicación RS232 (comunicación serial), los datos serán enviados en el orden de:
Horas ( minutos ( segundos.
En el caso de que el programa detecte que no ha sido la primera vez en la que se esta ejecutando, entonces internamente el programa esperara a que sean las 24:00:00 hrs para que empiece la transmisión de los datos hacia el dispositivo electrónico de la manera en que fueron enviados por primera vez: Horas ( minutos ( segundos. Esto se realiza con el motivo de que si en el transcurso del día se llegara a perder un segundo por motivo de la lejanía entre
dispositivos, el programa pueda sincronizar cada 24 hrs, para que no se llegue a perder algún segundo, puesto que es de vital importancia mantener todos los dispositivos en sincronía y con los mismos horarios.
El envío de los datos se realiza por el puerto serial de la computadora, mediante un cable con conectores usb-serial para que de esta manera pueda haber comunicación entre la PC y el dispositivo electrónico Master.
[pic]
Imagen 40.- Convertidor USB-Serial para la computadora
1. DESARROLLO DEL DISPOSITIVO MASTER.
Una vez realizado la parte donde se obtiene principalmente la hora, es necesario realizar el dispositivo electrónico que sea capaz de recibir los datos mandados por la computadora y que a su vez pueda actuar como un dispositivo Master ante los demás dispositivos electrónicos.
Para poder realizar esta parte del prototipo es necesario la utilización de varios materiales que en conjunto, podrán recibir la información enviada por la computadora y también podrá enviar los datos hacia los demás dispositivos. A continuación se explican las fases que se necesito para el desarrollo y ademas de los componentes utilizados para la elaboración.
1 RECEPCIÓN DE LOS DATOS.
En esta parte del prototipo corresponde al como se va a recibir la información mandada de la computadora, para esto es necesario la utilización de circuito integrado llamado MAX232.
El Max232 es muy útil para comunicar la computadora con un microcontrolador, debido a que la computadora maneja voltajes de 8 a -8v, por lo que no se puede conectar directamente a un microcontrolador que manejan voltajes TTL (5v), entonces de esta manera el Max232 actúa como un conversor de voltaje para poder interactuar entre una computadora y un microcontrolador.
La manera en la que se debe de diseñar el circuito del Max232 es de la siguiente forma:
[pic]
Imagen 41.- Esquema de funcionamiento del circuito Max232
El circuito integrado lleva internamente 2 conversores de nivel de TTL a rs232 y otros 2 de rs232 a TTL con lo que en total podremos manejar 4 señales del puerto serie del PC. Para que el max232 funcione correctamente deberemos de poner unos capacitores externos en la que solo se han cableado las líneas TX y RX que son las que se utilizaron para la realización del envío de datos desde la computadora y los otras dos líneas son las que utilizaremos para lograr la recepción.
Los valores de los capacitores utilizados en el circuito electrónico son de 100 nF.
En la siguiente imagen se muestra la manera en la que quedo montado sobre una placa el circuito integrado Max232 junto con los capacitores de 100 nf y el conector RS232 hembra.
[pic]
Imagen 42.- Vista del Max232 en placa
Con esto queda resuelto la parte de la comunicación entre la computadora y el dispositivo que recibirá la información.
1. MICROCONTROLADOR.
Ya se ha visto la forma del como se envían los datos desde la computadora y del como debemos de tener un circuito externo a la computadora para lograr establecer una comunicación con dicho circuito, después de haber realizado todo esto tenemos que tener un circuito integrado capaz de almacenar y trabajar información y para esto utilizamos el microcontrolador.
Un microcontrolador es un circuito integrado o chip que incluye en su interior las tres unidades funcionales de una computadora: CPU, Memoria y Unidades de E/S, es decir, se trata de un computador completo en un solo circuito integrado.
[pic]
Imagen 43.- Esquema de funcionamiento de un Microcontrolador
Para la realización de este prototipo el microcontrolador utilizado fue un ATmega32 que proviene de la familia ATMEL, este tiene el fin de recibir la información mandada por la
computadora, almacenarla y procesarla de tal manera que tambien pueda enviar los datos obtenidos hacia los otros dispositivos.
[pic]
Imagen 44.- Microcontrolador (ATmega32)
En el siguiente diagrama de flujo se explica la forma en la que trabaja el microcontrolador internamente utilizando la lógica para este prototipo.
[pic]
Imagen 45.- Diagrama de Flujo del funcionamiento del programa en el microcontrolador
Como primera acción del microcontrolador debe ajustar internamente los puertos de entrada y salida, a si como los registros que utilizan para el Timer/Counter, una vez realizado esta operación el microcontrolador espera a que algún dato sea recibido, que en este caso los datos serian las horas, minutos y segundos enviados por la computadora, cuando el microcontrolador adquiere la información ejecuta por comandos de código un reloj y lo despliega en pantalla, cuando en algún momento del programa recibe el refresh (que en este ocurre cuando son las 24:00:00 hrs y que sirve para que no exista algún desajuste de tiempos entre la computadora y el dispositivo) manda inmediatamente la información que le es enviada de la computadora hacia los otros dispositivos, para que así de este modo todos los relojes Slave se mantengan en sincronía. Si no se recibe el refresh el reloj se sigue ejecutando normalmente y puede que en unos días exista un desajuste de segundos.
Algo muy importante dentro del prototipo es la generacion de 1 seg exacto ya que si en esto existira un desajuste de reloj entre la computadora y el dispositivo Master.
Para esto se debe de contar con un cristal de 4 Mhz y dos capacitores de 33 pf como los que se muestran en la siguiente imagen:
[pic]
Imagen 46.- Capacitores y Cristal utilizados
Una vez que tenemos este material debemos de conectar el cristal en paralelo con las entradas de XTAL1 Y XTAL2 que se encuentran ubicadas en el microcontrolador, a si como tambien se
deben de poner los capasitores conectados del XTAL1 a GND y XTAL2 a GND respectivamente tal y como se muestra en la siguiente imagen:
[pic]
Imagen 47.- Diagrana de conexion del cristal
Una vez realizado este circuito se le debe de informar al microcontrolador que deberá de trabajar con un reloj externo para que así los procesos los haga conforme a la velocidad del cristal externo.
A continuación se muestra una imagen del como queda conectado el cristal junto con los dos capacitores en el prototipo.
[pic]
Imagen 48.- Conexión del cristal y capacitores en el microcontrolador
2. VISUALIZACION EN UN LCD.
El lcd (Liquid Crystal Display) es una de las herramientas utilizadas para la realización del prototipo ya que en el se pueden mostrar, tanto números como letras y es de gran importancia, por que en algún momento debemos saber las operaciones que estamos realizando con nuestro prototipo.
El lcd que se ocupo es el que se muestra en la siguiente imagen:
[pic]
Imagen 49.- LCD
En esta parte del prototipo se tuvo que implementar la conexión del lcd hacia el microcontrolador para poder desplegar la hora que es adquirida desde la computadora, una vez hecha esta operación sera facil ver que los dos relojes, tanto el de la computadora como el realizado por el microcontrolador mantengan las mismas horas, minutos y los segundos para asi poder comprobar que existe una sincronía entre estos dos.
En la siguiente imagen se muestra la conexión del lcd hacia el microcontrolador para que se pueda desplegar la hora.
[pic]
Imagen 50.- Diagrama de conexión del LCD
La siguiente imagen muestra el como quedo conectado el lcd con el microcontrolador para poder utilizarlo en el prototipo, con esto solo basta con alimentar con 5 V el circuito armado y tener un programa cargado en el microcontrolador para que se pueda desplegar algo en el lcd.
[pic]
Imagen 51.- Conexion del LCD con el microcontrolador
Una vez terminado todo lo descrito anteriormente solo queda el poder comprobar que el circuito electronico Master funciona correctamente junto con la computadora para asi poder dar por finalizado la recepcion de datos en el dispositivo electrónico Master.
En la siguiente imagen muestra todo el proceso que se lleva hasta el momento del prototipo.
[pic]
Imagen 52.- Modo de funcionamiento del dispositivo Master
En resumen de toda esta fase la interfaz de Visual Basic sirve para poder obtener la hora actual del sistema de una computadora, para asi después poder mandarla por el puerto serial de la Pc por el convertidor de cable usb-serial la información y por este medio poder conectar la computadora con nuestro circuito que contiene al Max232 el cual sirve para poder hacer la conversión de volatejes que viene de la Pc a voltajes TTL y asi lograr comunicarse con el microcontrolador, que con la información obtenida lo que hace internamente es generar un reloj que este sincronizado con el de la computadora, para que finalmente se pueda desplegar la hora en el lcd.
Las siguientes imágenes muestran todo el circuito armado y conectado con la computadora.
[pic]
Imagen 53.- Conexión del Dispositivo completo
[pic]
Imagen 54.- Conexión del Dispositivo Master
2 ENVIÓ DE DATOS.
Otras de las principales acciones que debe de realizar el dispositivo master es la de que una vez que reciba la hora proporcionada por la computadora sea capaza de transmitirla hacia los demás dispositivos electrónicos para poder mantener entre todos una sincronía.
El envío de los datos en el microcontrolador se hace mediante el pin TXD y que a su vez debe de estar programado para poder hacer el envío de datos através de ese pin.
[pic]
Imagen 55.- Diagrama de conexiones de TXD y RXD
2 DESARROLLO DEL DISPOSITIVO SLAVE
Los dispositivos Slaves tienen un lugar importante dentro del prototipo, por que son los dispositivos que serán colocados dentro de cada uno de los foros donde se requiera saber la hora que posee el dispositivo master, la elaboración de los slaves consta de algunas partes las cuales serán explicadas a continuación.
1 RECEPCION DE DATOS.
La función de la recepción de datos se realiza de la misma manera en la cual se hace en el dispositivo Master, la información es adquirida por el pin RXD que es uno de los pines que posee el microcontrolador y es almacenada y un programa que es previamente cargado.
Como es una comunicación serial entre los dos dispositivos el Slave tiene que esperar a que el dispositivo master le envie la hora para asi poder guardarla en una variable.
En el microcontrolador la recepción debe habilitarse para que en cualquier momento pueda recibirse un dato, el cual será alojado en el registro UDR. [pic]
Imagen 56.- Funcionamiento del RXD en el microcontrolador
1. COMUNICACIÓN ENTRE MICROCONTROLADORES.
[pic]
Imagen 57.- Conexión de mas dispositivos Slaves
Este modo implica un esquema maestro-esclavos. Cada esclavo tendrá una dirección que lo distinga de los demás. Pueden ser hasta 256 esclavos.
La comunicación se realiza con un formato de 9 bits, donde el 9º bit (transmitido en TXB8 o recibido en RXB8) sirve para distinguir entre campos de datos o dirección:
O ( DATOS
1 ( DIRECCIÓN
Donde esta comunicación se realiza de la siguiente manera:
□ Todos los esclavos deben habilitar el modo de multiprocesadores (MPCM = 1). Con ello pueden recibir campos de dirección.
□ El maestro envía una dirección, la cual es recibida por todos los esclavos.
□ Cada esclavo debe leer su registro UDR para determinar si ha sido seleccionado. El que resulte seleccionado debe limpiar su bit MPCM en el registro UCSRA.
□ El esclavo seleccionado y el maestro realizan un intercambio de datos, el cual pasa desapercibido por el resto de los esclavos, por que aún tienen su bit MPCM en alto.
□ Cuando se concluye el diálogo, el esclavo seleccionado debe poner en alto su bit MPCM, quedando junto con el resto de los esclavos, en espera de que el maestro solicite su atención.
Una vez que la comunicación entre microcontroladores Master/Slave es realizada y la recepcion del dato es adquirida por el Slave solo queda el visualizar la hora en un display de 7 segmentos que son los que se utilizaron en el desarrollo del prototipo.
[pic]
Imagen 58.- Displays utilizados
El display está formado por un conjunto de 7 leds conectados en un punto común en su salida. Cuando la salida es común en los ánodos, el display es llamado de ánodo común y por el contrario, sí la salida es común en los cátodos, llamamos al display de cátodo común. En la figura se muestran ambos tipos de dispositivos. En el display de cátodo común, una señal alta encenderá el segmento excitado por la señal. La alimentación de cierta combinación de leds, dará una imagen visual de un dígito de 0 a 9.
[pic]
Imagen 59.- Conexiones de Display Ánodo y Cátodo
Para lograr que exista una comunicación entre el microcontrolador y los display de 7 segmentos en necesario contar con un decodificador de BCD a 7 segmentos el cual requiere de una entrada en código decimal binario BCD y siete salidas conectadas a cada segmento del display. En la siguiente figura se representa en un diagrama de bloques el decodificador de BCD a 7 segmentos con un display de cátodo común.
[pic]
Imagen 60.- Conexion del Decodificador con el display de 7 segmentos
En este caso el visualizador es un display de cátodo común, se obtiene una tabla cuyas entradas en código BCD corresponden a A, B, C y D y unas salidas correspondientes a los leds que se encenderán en cada caso para indicar el dígito decimal.
[pic]
Tabla 5.- Valores de entradas y salidas para BCD
Los valores binarios 1010 a 1111 en BCD nunca se presentan, entonces las salidas se tratan como condiciones de no importa.
Con todo esto solo queda el montar todo el Dispositivo Slave completo, tal y como lo son el microcontrolador para la recepción de los datos enviados por el Master, el Decodificador BCD para lograr la comunicación entre los displays, y los displays de 7 segmentos que son los que al final mostraran al usuario la hora actual.
[pic]
Imagen 61.- Conexion del microcontrolador con el display de 7 segmentos
CAPITULO IV PRUEBAS Y AJUSTES.
4.1 PRUEBAS
Dentro de la realización de los dispositivos tanto el dispositivo Master como el dispositivo Slave se tuvo que realizar diferentes tipos de pruebas para corroborar que los dispositivos funcionen correctamente.
1 PRUEBA DEL PROGRAMA EN VISUAL BASIC.
Uno de los principales problemas con lo que se contó dentro la realización del prototipo, fue de compatibilidad entre Microsoft Windows Vista con el IDE Visual Basic, ya que Windows Vista maneja diferentes tipos de drivers y controladores a los que contaba Windows XP y debido a esto Visual Basic funciona correctamente bajo XP.
Para ese caso en el que se utilizo de sistema operativo Windows vista se tuvo que optimizar y mover algunos parámetros para que se pudiera instalar el IDE Visual Basic, y así poder realizar el programa que funciona en conjunto con el dispositivo Master para poder asignar las horas a los demás Slave´s.
El primer paso para comprobar que funciona correctamente, fue en dejar en ejecución el programa hecho en Visual Basic durante un aproximado de 5 horas y notar que el reloj no se desajuste con respecto a la hora de la computadora.
Una vez realizada esta prueba se hizo un programa en el cual serviría para comprobar la comunicación del RS232 de los puertos de la computadora para el envío de información hacia el dispositivo electrónico Master.
[pic]
Imagen 62.- Problemas de compatibilidad
2 PRUEBA DE COMUNICACIÓN ENTRE VISUAL BASIC Y DISPOSITIVO MASTER
Dentro de la realización de esta prueba se obtuvieron varios errores de comunicación entre Visual Basic y el dispositivo Master.
Los errores mas comunes que se tuvo en las pruebas de comunicación se encuentran los siguientes:
□ Frecuencia del reloj interno del microcontrolador mal establecido.
□ Establecimiento de Baud Rate (bps) en visual Basic mal establecido.
□ Mala elección del UBRR dentro del microcontrolador.
[pic]
Tabla 6.- Ejemplos de UBRR y frecuencias
[pic]
Imagen 63.- Parámetros del MsComm en Visual Basic
Para el microcontrolador se tuvo que agregar un cristal de 4 Mhz en paralelo con dos capacitores de 33 pf, para así poder obtener la precisión de un segundo, debido a que primeramente se utilizo el reloj interno del microcontrolador, que el cual funcionaba correctamente pero al cabo de cada 2 minutos de ejecución adquiría una perdida de 1 seg, y con esto al cabo del termino del día significaría una gran diferencia con respecto a cualquier reloj tanto de computadora como los de pared.
Una vez ajustado el dispositivo master con sus correspondientes valores, se probó el dispositivo completo, para comprobar el funcionamiento durante un aproximado de 2 hrs, donde el cual se obtuvo un correcto funcionamiento del dispositivo.
3 PRUEBA DE ENVIO DE DATOS ENTRE MICROCONTROLADORES.
Algo muy importante que se debe de comprobar antes de proseguir con todo prototipo, es el de verificar el correcto funcionamiento de cada uno de los microcontroladores que se utilicen dentro del prototipo.
Esto se hace realizando un programa para los microcontroladores, donde los dos integrados envíen y reciban información por los pines RXD y TXD que son los que se utilizan para una comunicación serial entre estos integrados.
Para la realización del programa que envie datos por medio del pin TXD se tiene que hacer lo siguiente:
void USART_Transmit( unsigned char data )
{
/* Wait for empty transmit buffer */
while ( !( UCSRA & (1