Descarga este documento en formato PDF - Ucontrol

4 de 22
Según Tanenbaum, una de las personalidades más reconocidas en el mundo académico de los SO, no es fácil
dar una definición definitiva de lo que es un SO. El problema consiste en que los SO tienen la característica de
comportarse para el usuario (que puede ser una persona cualquiera, un programador, o un programa de
computadora), como un tipo con "doble personalidad".
Veamos esto con más detenimiento:
1) El SO como máquina extendida:
En esta faceta de la personalidad del SO, la característica destacable es simplificar al programador los detalles
del funcionamiento de los dispositivos conectados al sistema.
Esta característica se pone también de manifiesto en aplicaciones donde no se usan los SO, un ejemplo típico
son las funciones output_x() e input_x() del compilador CCS. Un programador puede utilizar estas funciones
sin conocer que para que los datos se pongan en los pines o se lean, hay que cambiar varios registros en el
uC. Se dice que estas funciones son una abstracción del proceso de E/S en puerto. Esto es bueno porque
ayuda a los programadores a desarrollar soluciones más rápidamente y con menor probabilidad de errores ya
que si la función está bien escrita es poco probable que falle.
La función de la máquina extendida es ofrecer al programador una "interfaz" gracias a la cual se utilizan los
recursos del sistema, sin tener que profundizar demasiado en los detalles del funcionamiento de sus diferentes
componentes. Esta interfaz que el SO ofrece al programador o el usuario, se conoce comúnmente como
Llamadas al Sistema o API (Aplication Programmer Interface).
Sin embargo esta visión de los sistemas operativos es poco aplicable a nuestro entorno, en el sentido en que
hoy se clasifican a las llamadas al sistema, ya que en nuestro mundo todo es pequeño en cuanto a capacidad y
el crear una máquina extendida poderosa consume recursos que usualmente no tendremos. Entonces en este
caso la máquina extendida queda limitada a algunas llamadas a funciones del SO y al uso de las librerías que
hasta el momento hemos utilizado habitualmente.
2) El SO como administrador de recursos:
En este caso el SO, se comporta como un administrador de nuestros recursos. La ventaja de tener alguien que
administre eficientemente los recursos consiste en que el SO ofrezca al usuario un conjunto de reglas para
compartir y hacer uso de los recursos disponibles con eficacia y eficiencia.
Un ejemplo de administración de los recursos es el uso de la CPU, en un sistema sin SO, el programador tiene
que estar muy pendiente de la implementación de su sistema, porque puede que determinados requisitos
temporales en la ejecución de algunas funciones tengan que cumplirse.
En nuestro caso lo usual es que nos rompamos el coco manipulando interrupciones, poniendo demoras,
cambiando contadores y chequeando banderas… ¡Uf solo de pensarlo me dan ganas de llorar! Sin embargo un
SO puede hacerse cargo de todos esos temas de manera eficaz y eficiente, incluso ahorrando memoria y
tiempo, y nosotros los programadores concentrarnos en la implementación de la solución, más que en la
gestión eficiente de nuestros recursos.
Por supuesto que el SO no es mago ni adivino, para ello debe ofrecernos un conjunto de mecanismos,
relativamente sencillos, que nos ayuden a "indicarle" o "pedirle" que es lo que queremos hacer.
En el caso de los uC, las implementaciones de los SO, se caracterizan por potenciar la administración de
recursos del SO, por lo que es esta la faceta de personalidad que más a menudo encontraremos en los RTOS.
[Volver al Índice]
> Clasificación de los SO.:
A continuación veremos como se clasifican los SO en cuanto a dos características esenciales: la administración
del recurso fundamental (el procesador) y el destino del SO.
Los SO se pueden clasificar de distintas maneras, pero para abreviar lo más posible, solamente me voy a
referir a las ya mencionadas.
En cuanto a la administración del procesador existen dos clasificaciones:
1) SO cooperativo (no preemptive):
En este caso es el programador quién tiene la responsabilidad de entregarle el procesador al núcleo del SO,
para que éste lo entregue a la próxima tarea que esté solicitándolo o programada para ejecutarse. Es
entonces, muy importante, que las llamadas a funciones que ejecutemos nunca se queden esperando mucho
tiempo por determinados eventos, evitar los lazos infinitos y entregar el procesador cuando no lo necesitemos,
para que otra tarea o proceso pueda utilizarlo.
2) SO de tiempo compartido (preemptive):
En este caso el programador debe contar con los mismos mecanismos que en el anterior, pero el SO tiene la
facultad de quitarle el procesador y dárselo a otro si usted se ha excedido en su tiempo o hay alguien que tiene