Sistema operativo de tiempo real

Un sistema operativo de tiempo real es aquel que ha sido desarrollado para aplicaciones de tiempo real. Como tal, se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Si no las respeta, se dirá que el sistema ha fallado. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible...

Donde utilizarlos

Este tipo de sistemas son usados típicamente para aplicaciones integradas que normalmente tienen las siguientes caracteristicas:

• Utilizan poca memoria
• Cualquier evento en el soporte físico puede hacer que se ejecute una tarea
• Multi-arquitectura
• Tiempos de respuesta predecibles para eventos electrónicos

Características Generales

Usado típicamente para aplicaciones integradas, normalmente tiene las siguientes características:

• No utiliza mucha memoria
• Cualquier evento en el soporte físico puede hacer que se ejecute una tarea
• Multi-arquitectura (código portado a cualquier tipo de CPU)
• Muchos tienen tiempos de respuesta predecibles para eventos electrónicos
• Comunicación entre procesos:

Las comunicaciones entre procesos están soportadas de una manera precisa y estable, empleando mecanismos como el uso de semáforos, el paso de mensajes y el uso de memoria compartida.

• Determinismo:

Realiza operaciones en instantes de tiempo fijos predeterminados o dentro de intervalos de tiempo predeterminados. Cuando múltiples procesos compiten por recursos y tiempo de procesador, ningún sistema puede ser totalmente determinista. En un sistema operativo de tiempo real, las solicitudes de servicio de los procesos son dirigidas por eventos externos y temporizaciones. El grado en el que un sistema operativo puede satisfacer de manera determinista las solicitudes depende, primero, de la velocidad a la que es capaz de responder a las interrupciones y, segundo, de si el sistema tiene capacidad suficiente para manejar todas las solicitudes dentro del tiempo requerido. En sistemas operativos no de tiempo real, este retardo puede estar en el rango de decenas a cientos de milisegundos, mientras que en un sistema operativo de tiempo real este retardo puede tener un límite superior en algún punto entre los pocos microsegundos y el milisegundo.

• Reactividad:

Cuánto tiempo tarda el sistema operativo, después del reconocimiento, en servir la interrupción. La reactividad incluye los siguientes aspectos: 1. La cantidad de tiempo necesario para manejar inicialmente la interrupción y comenzar a ejecutar la rutina de servicio de la interrupción (RSI). Si la ejecución de la RSI necesita un cambio de proceso, entonces el retardo será mayor que si la RSI puede ser ejecutada dentro del contexto del proceso actual. 2. La cantidad de tiempo necesario para realizar la RSI. Esto depende, generalmente, de la plataforma hardware. 3. El efecto del anidamiento de interrupciones. Si una RSI puede ser interrumpida por la llegada de otra interrupción, entonces el servicio se retrasará. El determinismo y la reactividad juntos conforman el tiempo de respuesta a eventos externos. Los requisitos de tiempo de respuesta son críticos para los sistemas de tiempo real, dado que estos sistemas deben cumplir requisitos de tiempo impuestos por individuos, dispositivos o flujos de datos ex- ternos al sistema.

• Control del usuario :

En un sistema operativo no de tiempo real, el usuario no tiene control sobre la función de planificación o bien el sistema operativo sólo puede proporcionar una guía burda, como la agrupación de usuarios en más de una clase de prioridad. En un sistema de tiempo real es esencial permitirle al usuario un control de grano fino sobre la prioridad de la tarea. El usuario debe ser capaz de distinguir entre tareas duras y suaves y de especificar prioridades relativas dentro de cada clase. Un sistema de tiempo real puede también permitirle al usuario especificar características como el uso de paginación en los procesos, qué procesos deben residir siempre en memoria principal, qué algoritmos de transferencia a disco deben utilizarse, qué derechos tienen los procesos de las varias bandas de prioridad, etcétera.

• Fiabilidad:

Un sistema de tiempo real ha de responder y controlar eventos en tiempo real. La pérdida o degradación de sus prestaciones puede tener consecuencias catastróficas.

• Operación de fallo suave:

Se refiere a la habilidad del sistema de fallar de tal manera que se preserve tanta capacidad y datos como sea posible. Un sistema de tiempo real intentará o bien corregir el problema o bien minimizar sus efectos continuando, en todo caso, en ejecución. Un sistema de tiempo real es estable si, en los casos en los que sea imposible cumplir los plazos de todas las tareas, el sistema cumplirá los plazos de sus tareas más críticas, de más alta prioridad, aunque los plazos de algunas tareas menos críticas no se satisfagan. Para cumplir los requisitos precedentes, los sistemas operativos de tiempo real incluyen de forma representativa las siguientes características

• Cambio de proceso o hilo rápido.
• Pequeño tamaño (que está asociado con funcionalidades mínimas).
• Capacidad para responder rápidamente a interrupciones externas.
• Multitarea con herramientas para la comunicación entre procesos como semáforos, señales y eventos.
• Utilización de ficheros secuenciales especiales que pueden acumular datos a alta velocidad.
• Planificación expulsiva basada en prioridades.
• Minimización de los intervalos durante los cuales se deshabilitan las interrupciones.
• Primitivas para retardar tareas durante una cantidad dada de tiempo y para parar/retomar tareas.
• Alarmas y temporizaciones especiales.

Lo más importante de un sistema de tiempo real es el planificador de tareas a corto plazo. En el diseño de tal planificador, la equidad y la minimización del tiempo medio de respuesta no son lo más importante. Lo que es importante es que todas las tareas de tiempo real duro se completen (o comiencen) en su plazo y que tantas tareas de tiempo real suave como sea posible también se completen (o comiencen) en su plazo.

Ventajas

Un Sistema Operativo en Tiempo Real es pequeño, rápido, receptivo y determinista. Esto significa que ejecutará tareas de manera rápida y eficiente, respondiendo como se espera cada vez. Debido a la importancia de su dispositivo host, la infraestructura RTOS es más segura y es menos probable que se bloquee o falle. Finalmente, un RTOS está orientado al desarrollador, lo que significa que continúa implementando actualizaciones que ayudan a los usuarios a codificar de manera más efectiva.

Componentes de un sistema operativo

Un sistema operativo posee tres componentes esenciales o paquetes de software que permiten la interacción con el hardware.

• Sistema de archivos. Es el registro de archivos donde adquieren una estructura arbórea.
• Interpretación de comandos. Se logra con aquellos componentes que permiten la interpretación de los comandos, que tienen como función comunicar las órdenes dadas por el usuario en un lenguaje que el hardware pueda interpretar (sin que aquel que dé las órdenes conozca dicho lenguaje).
• Núcleo. Permite el funcionamiento en cuestiones básicas como la comunicación, entrada y salida de datos, gestión de procesos y la memoria, entre otros.

Procesador

Este tipo de sistemas operativos no es necesariamente eficiente en el sentido de tener una capacidad de procesamiento alta. El algoritmo de programación especializado, y a veces una tasa de interrupción del reloj alta pueden interferir en la capacidad de procesamiento.

Aunque para propósito general un procesador moderno suele ser más rápido, para programación en tiempo real deben utilizarse procesadores lo más predecibles posible, sin paginación. Todos estos factores en un procesador añade una aleatoriedad que hace que sea difícil demostrar que el sistema es viable, es decir, que cumpla con los plazos de tiempo para la ejecución de las tareas y la atención de los servicios o interrupciones.

Un sistema operativo de tiempo real puede ser implementado en microcontroladores o procesadores digitales de señal "DSP's", así, se pueden desarrollar aplicaciones embebidas en diferentes áreas de la electrónica.

Diseño

Hay dos diseños básicos:

• Un sistema operativo guiado por eventos: sólo cambia de tarea cuando un evento necesita el servicio.
• Un diseño de compartición de tiempo: cambia de tareas por interrupciones del reloj y por eventos.

El diseño de compartición de tiempo gasta más tiempo de la CPU en cambios de tarea innecesarios. Sin embargo, da una mejor ilusión de multitarea. Normalmente se utiliza un sistema de prioridades fijas.

Uno de los algoritmos que suelen usarse para la asignación de prioridades es el Rate-Monotonic Schedule. Si el conjunto de tareas que tenemos es viable con alguna asignación de prioridades fijas, también es viable con el Rate-Monotonic Schedule, donde la tarea más prioritaria es la de menor periodo. Esto no quiere decir que si no es viable con Rate-Monotonic Schedule no sea viable con asignaciones de prioridad variable. Puede darse el caso de encontrarnos con un sistema viable con prioridades variables y que no sea viable con prioridades fijas.

Programación

En los diseños típicos, una tarea tiene tres estados: ejecución, preparada y bloqueada. La mayoría de las tareas están bloqueadas casi todo el tiempo. Solamente se ejecuta una tarea por UCP. La lista de tareas preparadas suele ser corta, de dos o tres tareas como mucho.

El problema principal es diseñar el programador. Usualmente, la estructura de los datos de la lista de tareas preparadas en el programador está diseñada para que cada búsqueda, inserción y eliminación necesiten interrupciones de cierre solamente durante un período muy pequeño, cuando se buscan partes de la lista muy definidas.

Esto significa que otras tareas pueden operar en la lista asincrónicamente, mientras que se busca. Una buena programación típica es una lista conectada bidireccional de tareas preparadas, ordenadas por orden de prioridad. Hay que tener en cuenta que no es rápido de buscar sino determinista. La mayoría de las listas de tareas preparadas sólo tienen dos o tres entradas, por lo que una búsqueda secuencial es usualmente la más rápida, porque requiere muy poco tiempo de instalación.

El tiempo de respuesta crítico es el tiempo que necesita para poner en la cola una nueva tarea preparada y restaurar el estado de la tarea de más alta prioridad.

En un sistema operativo en tiempo real bien diseñado, preparar una nueva tarea necesita de 3 a 20 instrucciones por cada entrada en la cola y la restauración de la tarea preparada de máxima prioridad de 5 a 30 instrucciones. En un procesador 68000 20MHz, los tiempos de cambio de tarea son de 20 microsegundos con dos tareas preparadas.

Cientos de UCP MIP ARM pueden cambiar en unos pocos microsegundos.

Objetos

Los objetos de Sistemas Operativos de Tiempo Real son capaces de compartir información y sincronizar la ejecución de tareas. La mayoría de estos sistemas tienen objetos como:

• Cola de mensajes
  • Cola de entrada y salida (FIFO) para el paso de datos
  • Los datos pueden enviarse por copia o por referencia (puntero)
  • Se utiliza para enviar datos entre tareas o entre interrupción y tarea

• Semáforo
  • Puede tratarse como un contador de referencia para registrar la disponibilidad de un determinado curso
  • Puede ser un semáforo binario o de conteo
  • Se utiliza para vigilar el uso de recursos o sincronizar la ejecución de tareas

• Mutex
  • Similar al semáforo binario, generalmente utilizado para proteger el uso de un solo recurso (exclusión mutua)
  • El mutex de FreeRTOS viene con un mecanismo de herencia de prioridades para evitar el problema de la inversión de prioridades (condición en la que una tarea de alta prioridad termina esperando a otra de menor prioridad)

• Buzón
  • Almacén simple para compartir una sola variable
  • Puede considerarse como una cola de un solo elemento

• Grupo de eventos
  • Grupo de condiciones (disponibilidad de semáforo, cola, bandera de evento, etc.)
  • La tarea puede bloquearse y esperar a que se cumpla una condición de combinación específica
  • Disponible en Zephyr como API de sondeo, en FreeRTOS como QueueSets

Comunicación entre Tareas

Las diferentes tareas de un sistema no pueden utilizar los mismos datos o componentes físicos al mismo tiempo. Hay dos métodos para tratar este problema.

Uno de los métodos utiliza semáforos. En general, el semáforo binario puede estar cerrado o abierto. Cuando está cerrado hay una cola de tareas esperando la apertura del semáforo.

Los problemas con los diseños de semáforos son bien conocidos: inversión de prioridades y Bloqueo mutuo (deadlocks).

En la inversión de prioridades, una tarea de mucha prioridad espera porque otra tarea de baja prioridad tiene un semáforo. Si una tarea de prioridad intermedia impide la ejecución de la tarea de menor prioridad, la de más alta prioridad nunca llega a ejecutarse. Una solución típica sería otorgar a la tarea que tiene el semáforo la prioridad de la tarea más prioritaria de las que están esperando dicho semáforo. Esto se denomina algoritmo de herencia básica de prioridad.

En un punto muerto, dos tareas (T1,T2) pretenden adquirir dos semáforos (semA, semB) en orden inverso. En este caso si T1 adquiere semA y T2 adquiere semB cuando intenten adquirir el segundo semáforo no podrán hacerlo ya que lo tiene la otra tarea. De esta forma entran en un punto muerto del que ninguna de las dos tareas puede salir sin intervención externa. Esto se resuelve normalmente mediante un diseño por ej. obligando a adquirir los semáforos en un orden concreto.

La otra solución es que las tareas se manden mensajes entre ellas. Esto tiene los mismos problemas: La inversión de prioridades tiene lugar cuando una tarea está tratando un mensaje de baja prioridad, e ignora un mensaje de más alta prioridad en su correo. Los puntos muertos ocurren cuando dos tareas realizan envíos bloqueantes (se quedan en la función de envío esperando a que el receptor reciba el mensaje). Si T1 manda un mensaje de forma bloqueante a T2 y T2 manda un mensaje de igual forma a T1 ninguna de las dos tareas saldrá de la función de envío quedando ambas bloqueadas ya que no podrán llegar a la función de recepción. Puede resolverse reordenando envíos y recepciones o empleando envíos no bloqueantes o temporizados.

Aunque su comportamiento en tiempo real es algo más difícil de analizar que los sistemas de semáforos, los sistemas basados en mensajes normalmente son más sencillos de desarrollar que los sistemas de semáforo.

Interrupciones

Las interrupciones son la forma más común de pasar información desde el mundo exterior al programa y son, por naturaleza, impredecibles. En un sistema de tiempo real estas interrupciones pueden informar diferentes eventos como la presencia de nueva información en un puerto de comunicaciones, de una nueva muestra de audio en un equipo de sonido o de un nuevo cuadro de imagen en una videograbadora digital.

Para que el programa cumpla con su cometido de ser tiempo real es necesario que el sistema atienda la interrupción y procese la información obtenida antes de que se presente la siguiente interrupción. Como el microprocesador normalmente solo puede atender una interrupción a la vez, es necesario que los controladores de tiempo real se ejecuten en el menor tiempo posible. Esto se logra no procesando la señal dentro de la interrupción, sino enviando un mensaje a una tarea o solucionando un semáforo que está siendo esperado por una tarea. El programador se encarga de activar la tarea y esta se encarga de adquirir la información y completar el procesamiento de la misma.

El tiempo que transcurre entre la generación de la interrupción y el momento en el cual ésta es atendida se llama latencia de interrupción. El inverso de esta latencia es una frecuencia llamada frecuencia de saturación, si las señales que están siendo procesadas tienen una frecuencia mayor a la de saturación, el sistema será físicamente incapaz de procesarlas. En todo caso la mayor frecuencia que puede procesarse es mucho menor que la frecuencia de saturación y depende de las operaciones que deban realizarse sobre la información recibida.

Memoria

Hay dos problemas con el reparto de la memoria en SOTR (sistemas operativos en tiempo real).

El primero, la velocidad del reparto es importante. Un esquema de reparto de memoria estándar recorre una lista conectada de longitud indeterminada para encontrar un bloque de memoria libre; sin embargo, esto no es aceptable ya que el reparto de la memoria debe ocurrir en un tiempo fijo en el SOTR.

En segundo lugar, la memoria puede fragmentarse cuando las regiones libres se pueden separar por regiones que están en uso. Esto puede provocar que se pare un programa, sin posibilidad de obtener memoria, aunque en teoría exista suficiente memoria. Una solución es tener una lista vinculada LIFO de bloques de memoria de tamaño fijo. Esto funciona asombrosamente bien en un sistema simple.

La paginación suele desactivarse en los sistemas en tiempo real, ya que es un factor bastante aleatorio e impredecible, que varía el tiempo de respuesta y no nos permite asegurar que se cumplirán los plazos, debido al trasiego de páginas de memoria con un dispositivo de almacenamiento (thrashing)

Planificación de tiempo real

Los distintos enfoques de la planificación dependen de 1. cuando el sistema realiza análisis de planificabilidad; y si lo hace, de 2. si se realiza estática o dinámicamente; y de 3. si el resultado del análisis produce un plan de planificación de acuerdo al cual se desarrollarán las tareas en tiempo de ejecución. En base a estas consideraciones se identifican las siguientes clases de algoritmos: • Enfoques estáticos dirigidos por tabla. En éstos se realiza un análisis estático de la factibilidad de la planificación. El resultado del análisis es una planificación que determina cuando, en tiempo de ejecución, debe comenzar a ejecutarse cada tarea. • Enfoques estáticos expulsivos dirigidos por prioridad. También se realiza un análisis está- tico, pero no se obtiene una planificación. En cambio, el análisis se utiliza para asignar prioridades a las tareas, y así puede utilizarse un planificador expulsivo tradicional basado en prioridades. • Enfoques dinámicos basados en un plan. La factibilidad se determina en tiempo de ejecución (dinámicamente) en vez de antes de comenzar la ejecución (estáticamente). Una nueva tarea será aceptada como ejecutable sólo si es posible satisfacer sus restricciones de tiempo. Uno de los resultados del análisis de factibilidad es un plan que se usará para decidir cuándo poner en marcha la tarea. • Enfoques dinámicos de mejor esfuerzo. No se realiza análisis de factibilidad. El sistema intenta cumplir todos los plazos y aborta la ejecución de cualquier proceso cuyo plazo haya fallado.

2.1) Planificación estática dirigida por tabla. Aplicable a tareas que son periódicas, los datos de entrada para el análisis son: tiempo periódico de llegada, tiempo de ejecución, plazo periódico de finalización, y prioridad relativa de cada tarea. El planificador intenta encontrar un plan que le permita cumplir todos los requisitos de todas las tareas periódicas. Éste es un enfoque predecible pero no flexible, un cambio en cualquiera de los requisitos de las tareas requiere rehacer toda la planificación. Algoritmos de planificación: plazo más cercano primero, técnicas de plazos periódicos. 2.2) Planificación estática con expulsión dirigida por prioridad. Hace uso del mecanismo de planificación expulsivo dirigido por prioridades, Fig. 2, En un sistema de tiempo real, la asignación de prioridades está relacionada con las restricciones de tiempo asociadas a cada tarea. Algoritmos de planificación: algoritmo de tasa monótona; asigna prioridades estáticas a las tareas basándose en sus longitudes y sus periodos. 2.3) Planificación dinámica basada en un plan. Cuando llega una nueva tarea, pero antes de que comience su ejecución, se intentará crear un plan que contenga las tareas previamente planificadas así como la nueva. Si la tarea recién llegada puede ser planificada de manera que se cumplan sus plazos sin que ninguna otra tarea planificada anteriormente pierda un plazo, la nueva tarea será aceptada poniéndose en marcha el nuevo plan de planificación. 2.4) Planificación dinámica de mejor esfuerzo. Cuando llega una tarea, el sistema le asigna una prioridad basada en las características de la misma. De forma característica se utiliza algún tipo de planificación basada en plazos como la planificación del plazo más cercano. Así, las tareas no son periódicas y por tanto no es posible realizar un análisis estático de planificabilidad. Con este tipo de planificación, no sabremos si una determinada restricción de tiempo será satisfecha hasta que venza su plazo o la tarea se complete.

Comunicaciones

Para las comunicaciones se suelen usar conexiones o redes deterministas CAN bus o puertos serie, ya que las redes más usuales, como Ethernet son indeterministas y no pueden garantizarnos el tiempo de respuesta. El sistema CAN bus es utilizado para la interconexión de dispositivos electrónicos de control (ECU) en los vehículos.

Tipos de Sistemas Operativos en Tiempo Real^[1]​

Tiempo real duro:

En estos tipos de sistemas operativos, los plazos de tiempo límite son muy estrictos lo que significa que las tareas que se realicen deben comenzar su ejecución en el tiempo programado especificado y debe completarse forzosamente dentro del periodo de tiempo que se le asigne.

Tiempo real firme:

En este tipo de sistema operativo también se debe cumplir con plazos de tiempo, sin embargo, el incumplimiento en algún plazo limite puede no ser de gran impacto por lo que existe cierta flexibilidad con el tiempo de finalización de la tarea lo puede causar efectos no deseados en el funcionamiento del sistema como la reducción de la calidad.

Tiempo real suave:

En este tipo se aceptan retrasos por parte del propio sistema operativo. Hay un periodo de tiempo límite para una tarea especifica pero son aceptables los retrasos que se puedan dar siempre y cuando el tiempo no sea muy alto, es decir se manejar retrasos suavemente.

Desventajas de utilizar Sistemas Operativos en Tiempo Real^[1]​

• Puede ejecutar tareas mínimas juntas y se concentra solo en aquellas aplicaciones que contienen un error para poder evitarlas.
• Es el sistema que se concentra en unas pocas tareas. Por lo tanto, es realmente difícil para estos sistemas realizar múltiples tareas.
• Se requieren controladores específicos para el sistema operativo para que pueda ofrecer un tiempo de respuesta rápido para interrumpir las señales, lo que ayuda a mantener su velocidad.
• Utiliza muchos recursos que a veces no son adecuados para el sistema, lo que hace que este sea costoso.
• Las tareas que tienen una prioridad baja deben esperar mucho tiempo ya que el sistema operativo mantiene la precisión del programa, que están en ejecución.
• El cambio mínimo de tareas se realiza en sistemas operativos en tiempo real.
• Utiliza algoritmos complejos que son difíciles de entender.

Aplicaciones

Muchos Sistemas Operativos de tiempo real son construidos para aplicaciones muy específicas como control de tráfico aéreo, bolsas de valores, control de refinerías, control de laminadores. También en la rama de la automovilística y de la electrónica de consumo, las aplicaciones de tiempo real están creciendo muy rápidamente.

Otros campos de aplicación de los Sistemas Operativos de tiempo real son los siguientes:

• Control de trenes
• Telecomunicaciones
• Sistemas de fabricación integrada
• Producción y distribución de energía eléctrica
• Control de edificios
• Sistemas multimedia

Relación con los Sistemas Embebidos^[2]​

Los sistemas embebidos son sistemas diseñados para realizar funciones especificas con características físicas limitadas donde la mayoría de sus componentes suelen estar incluidos en una placa base (sondas y sensores, botones, perilla de control, etc.) y con restricciones de tiempos cortos de respuesta.

El software en tiempo real es ideal para sistemas que deban cumplir con plazos específicos donde se debe garantizar que la predicción de la duración de la ejecución de tareas se realice con precisión. Los sistemas embebidos en tiempo real son una subcategoría de los sistemas embebidos que se centran en la ejecución oportuna de sus tarea por lo que se hace uso de software de tiempo real para lograr el objetivo.

Los sistemas embebidos, cuentan con procesos con protección que recupera recursos una vez que un proceso finaliza involuntariamente para evitar fugas de recursos. El sistema operativo se basa en técnicas de software, protección de memoria de hardware y distinción de supervisor/usuario dentro del conjunto de instrucciones del procesador para evitar accidentes de proceso o acciones maliciosas que dañen otros procesos y el sistema operativo por lo que el uso de un sistema operativo de tiempo real puede mejorar considerablemente el desempeño y la seguridad del sistema embebido.

Los sistemas operativos en tiempo real  se pueden considerar como una solución práctica para el uso de sistemas embebidos, especialmente en escenarios donde se requieren múltiples puntos de control para comportarse de manera predecible bajo niveles de prioridad controlados.

Algunos Ejemplos

• Haiku (sistema operativo)
• QNX
• PuyOL
• RT-11
• MaRTE OS
• EasyTasks
• LynxOS
• RedHat Embedded Linux
• eCos (Linux)
• SOOS
• VxWorks
• Windows CE
• Linchos
• UNIX (Algunos)
• DuinOS
• RTAI
• Symbian
• BlackBerry 10
• Microware OS-9
• FreeRTOS

Principales fabricantes

Principales fabricantes de sistemas RTOS en 2009^[3]​

•   Estados Unidos Nucleus RTOS (filial de Mentor Graphics)
•   Suecia ENEA OSE (filial de ENEA AB)
•   Estados Unidos Wind River Systems (filial de Intel Corporation)

Referencias

1. Williams, Lawrence (21 de enero de 2021). «Real-time operating system (RTOS): Components, Types, Examples». www.guru99.com (en inglés estadounidense). Consultado el 28 de mayo de 2022. 
2. «The Role of an RTOS in an Embedded System». IntervalZero (en inglés estadounidense). 7 de abril de 2018. Consultado el 28 de mayo de 2022. 
3. . Archivado desde el original el 14 de julio de 2014. Consultado el 13 de julio de 2014. 

Enlaces externos

• EasyTask OS
• MaRTE OS
• FreeRTOS

• Desarrollo de drivers y aplicaciones en sistemas embebidos (FreeRtos) (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). Ing. Marcelo Lorenzati, Universidad Nacional de Mar del Plata
• Foro FreeRTOS en castellano (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).

• SOOS Project
• Curso de FreeRTOS con microcontroladores PIC
• DuinOS (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
• Milos
• OsaRTOS para PIC

•   Datos: Q213666
•   Multimedia: Real-time operating systems / Q213666