| |
|
Desde que pulsamos el boton de encendido de nuestro PC hasta... (parte 3) |
|
|
|
| |
Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98
DESDE QUE PULSAMOS EL BOTON DE NUESTRO PC HASTA..... (Parte 3)
---------------------------------------------------- PLACA MADRE (NORMA DE COMPATIBILIDAD IBM)
----------------------------------------- Bien, llegado a este punto, y debido a las con-notaciones que tiene actualmente, es necesario introducir un par de chips basicos que se definieron en las placas madre primigenias. Son: * El controlador de Interrupciones * El controlador de DMA Recordemos, que siguen "exatamente" igual a como se definieron al principio. Tan exactamente igual, que hasta la frecuencia de funcionamiento del chip de DMA sigue siento de unos ridiculos 4 MHz, que quizá fuesen rapidos en su momento, pero que actualmente son ridiculos comparados con el resto de funcionamiento de una placa madre. (Recordad, entonces que hay que "huir" de los dispositivos que utilicen DMA, simplemente por su lentitud -y bloqueos de la CPU-. Igualmente recordad que la DMA y la UDMA no tienen *nada* que ver. Ya lo iremos viendo más adelante). Veamos primero, como puede comunicarse la CPU con el resto de dispositivos. Recordad que la CPU, tiene una serie de lineas de "control". Estas son las importantes para la mayoria de los dispositivos. Veamos las tres "unicas" maneras que tiene la CPU de "enterarse" o "recibir/enviar" datos a un dispositivo. Antes de eso, vamos a introducir que realmente la CPU, solo tiene dos instrucciones llamadas IN y OUT para poner un byte (o maximo, 2 bytes) en un "puerto". Y que un "puerto" no es nada mas que una dirección de destino que tiene algun chip o dispositivo de la placa madre. Un puerto, se dirección a con 2 bytes, es decir existe un maximo de 65535 puertos en un PC. Bueno, ya ahora ¿como podemos dirección ar un dispositivos, al cual sabemos que por "hardware" tiene un determinado (o determinados) puertos. ** Podemos mediante la instruccion IN poner datos en un puerto. La secuencia de datos que estamos poniendo para un determinado hardware, puede ser por ejemplo, una "peticion" de que ese hardware haga algo, o bien le estamos "escribiendo" datos, en vez de ordenes, etc.... Esto depende del dispositivo. Del hardware, en sí,... es decir del "manual" del fabricante de hardware (del manual "tecnico"). Igualmente, mediante la instruccion OUT, podemos "leer" un dato que un dispositivo nos haya dejado en un puerto. Perfecto!. Pero ahora ¿como nos enteramos que el dispositivo ya tiene un dato preparado para que lo leamos? Bueno, pues dos posiblidades: 1) A lo "bruto". Empezamos enviamos una peticion a un dispositivo (mediante la instruccion IN), y segun el manual del fabricante, ahora ese dispositivo, nos va a responder en un puerto. Pues bien, empezamos a leer (mediante OUT), de ese puerto hasta que exista un dato. Hala!, a lo loco!, OUT->no hay dato?->OUT->no hay dato?->OUT... Es decir nos metemos en un bucle, sin hacer nada más hasta encontrar el dato que nos dice el manual. Pero.... si por desgracia falla el dispositivo, o hemos programado mal la peticion que realizamos con el IN, pues... nos hemos metido en un "bucle" infinito. La CPU nunca tendrá ese dato y además la secuencia programada no se puede interrumpir....... malo, malo. Una mejora de esta solucion, sería mira unicamente cada cierto tiempo. Se puede hacer que se mire cada "tic" de reloj. Y ese "tic" de reloj interno lo podemos programar (exite tambien un circuito de "timer" para estas cosas). Bueno.... hemos mejorado, pero reconozcamos que estamos perdiendo mucho tiempo en "ver" si el hardware nos responde. * Este es el modo PIO (Program Input Output) 2) Un poco más sofisticado. Alguien inventó las IRQ (Interrupt Request). Es más logico: le pedimos algo al dispositivo, y nos dedicamos a hacer otras cosas. Cuando el dispositivo tenga el dato, simplemente que nos avise enviando una "interrupcion" (IRQ). Se llama así porque una interrupcion, interrumpe obligatoriamente lo que esté haciendo la CPU y la obliga a tomar alguna accion. Ya veremos cual. (en este caso por ejemplo, leer una vez del correspondiente puerto, porque tenemos la seguridad que ahora sí que hay dato). Estas interrupciones, pueden ser interrupciones hardware, o bien interrupciones software, las veremos tambien mas adelante. * Este es el metodo IRQ. ** Y existe un tercer metodo para llevar ciertos tipos de datos desde un dispositivo hardware. 3) Imaginemos que tenemos un "chip" inteligente, y que somos capaces de decirle que una vez que tenga LOS datos (digo "LOS", porque este chip admite programacion a nivel de decirle cuantos queremos), nos los pase a una dirección de memoria prefijada sin necesidad de que la CPU trabaje para nada. Esta es la tecnica DMA. Esta tecnica aparentemente genial tiene un incoveniente (mejor dicho dos). Primero, cuando el chip va a pasar los datos a la memoria, o desde la memoria, para asegurarse que nadie los toca, lo que hace es "desconectar" a la CPU del bus. Y mientras está "desconectada" la CPU no hace nada. Sufre un "parón". Bueno,... esto no era tan importante en la primera arquitectura del PC, con CPUs a 4,77 MHz, y una DMA rapida (4 MHZ), este tipo de acceso simplificaba la programacion y además era mas rapida que las tecnicas IN, OUT (tecnicas PIO). Pero por desgracia y para conservar la compatibilidad la velocidad de la DMA sigue siendo la velocidad primitiva (4 MHZ), y además por el mismo motivo, la DMA solo sabe hacer transferencias de 8 y 16 bits simultanemanete (cuando la memoria actual se dirección a en un bus de 32). Y ademas, por desgracia, mientras está haciendo la transferencia "interrumpe" a nuestro flamante PIII, que durante ese tiempo habría podido hacer cientos de miles de operaciones en multitarea. * Esta es la transferencia DMA. Bien retomando un poco el inicio de este capitulo, habiamos visto que existia el: ** Controlador programable de interrupciones. ¿y que hace este "bicho"?, pues facil, lo que hace es que cuando recibe una interrupcion, lo primero es enviar una señal a todo el hardware "prohibiendo" que se emitan mas interrupciones, y posteriormente se la comunica a la CPU mediante una linea de control especial (y unica!!). Se le llama "programable" ya que tiene la posibilidad de que si recibe "simultaneamente" mas de una interrupcion, puede ordenararlas por las prioridades que le haya programado el sistema operativo, para irselas dando a la CPU de una en una. Igualmente recordad, que como este controlador, ha prohibido las interrupciones, una vez que se ha notificado a la CPU de esta intrrupcion y la CPU ha llamado a la rutina de servicio (driver) que controla esta interrupcion, lo primero que tiene que hacer, en cuanto pueda, el "driver" es emitir una instruccion STI, es decir informar a todo el sistema que ya está permitido de nuevo enviar interrupciones. Fijaros, lo "peligroso" que puede ser un driver mal programado, simplemente porque al programador de turno se le olvida de vez en cuando el emitir una instruccion STI. IRQs (INTERRUPT REQUEST)
------------------------ Bueno, pues tambien arrastramos aquí una desgraciada herencia. Solo se definieron 16 IRQs (y ademas, no vectorizadas, por lo que en principio NO pueden compartirse. Ojo!!, he dicho en "principio"). Y además de "pocas", pues mal distribuidas. De base, sin tener NADA en el PC, están utilizadas: IRQ 0 Reloj del Sistema
IRQ 1 Teclado
IRQ 2 Controlador Programable de Interrupciones
IRQ 3 Puerto de Comunicaciones Serie 2
IRQ 4 Puerto de Comunicaciones Serie 1
IRQ 5 LIBRE
IRQ 6 Controlador de Disquetes
IRQ 7 Puerto paralelo.
IRQ 8 Reloj en tiepo real (CMOS de la BIOS)
IRQ 9 LIBRE
IRQ 10 LIBRE
IRQ 11 LIBRE
IRQ 12 LIBRE
IRQ 13 Coprocesador matematico
IRQ 14 Primer controlador IDE de disco duro
IRQ 15 Segundo controlador IDE de disco duro Fiejmonos que en principio, solo quedan 5 libres. Pero.... si tenemos raton en puerto de ratón, este utilizará la IRQ 12. Quedan 4. Si nuestra placa tiene bus USB, este necesita otra interrupcion, si además tenemos bios ACPI, esta necesita otra interrupcion..... y la tarjeta de red, otra, etc,etc,etc, Mala pinta tiene el asunto como para poder poner nuevas tarjetas ¿no? Vamos a introducir un poco los "buses" del sistema para dialogar con dispositivos. Allí veremos como a pesar de las restricciones que aparecen por las pocas IRQs libres, podemos llegar a un ten con ten con el hardware y el sistema operativo, para poder compartir al menos, alguna interrupcion entre varios dispositivos. Con esto de los "buses" debemos remitirnos otra vez a la "historia" de la evoluvion de las primeras placas madre y su enlace con las actuales BIOS y el sistema en general. Con esto ya podremos empezar a preguntarnos otra vez el tema del titulo de estos articulos: "Desde que pulsamos el boton de arranque hasta..." BUSES
===== *** Bueno, y este será el siguiente capitulo......
Volver a
Artículos y FAQs
| 
