Sistema operativo de tiempo real

Este artículo o sección necesita ser wikificado, por favor, edítalo para que cumpla con las convenciones de estilo. Este aviso fue puesto el 1 de noviembre de 2021.

Un sistema operativo en tiempo real (Real Time Operating System), también conocido como RTOS por sus siglas en inglés, es un sistema operativo liviano utilizado para desarrollar cosas íntimas e integrar tareas de diseño con recursos y tiempos específicos de manera óptima y sencilla como suele aplicar para los sistemas integrados. Es por ello que los dispositivos que usan sistemas operativos en tiempo real son considerados un subconjunto de los sistemas de control.

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

• 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

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
• Soporte para la planificación de procesos en tiempo real.
• Planificación por prioridad (pre-empite).
• Garantía de respuesta ante interrupciones.
• Comunicación interprocesos.
• Adquisición de datos a alta velocidad.
• Soporte de E/S (entrada/salida).
• Control por parte del usuario, de los recursos del sistema.
• 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.

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.

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.

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.

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

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.

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.

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)

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.

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.

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.

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.

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.

Adicionalmente son relativamente estables pero no muy robustos, pueden ser tolerantes a fallas, baja su desempeño con cargas excesivas de tareas por realizar, no es requisito la seguridad informática y de operación, pueden manejar grandes volúmenes de información

• 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.

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

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.

Existen algunas plataformas para establecer los sistemas, entre ellas están:

• VxWorks: está basado en Unix y es de tiempo real, y está especialmente diseñado para controlar sistemas delicados, robots, satélites, aviones e incluso hasta el propio Curiosity.
• Solaris, Lynxs OS: Solaris es un sistema operativo Unix desarrollado inicialmente por Sun Microsystems. Solaris es conocido por su escalabilidad, especialmente en sistemas SPARC, y por haber originado muchas características innovadoras, como DTrace, ZFS y Time Slider.
• Spectra

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

El primer paso para entender la plataforma FreeRTOS es explorar la organización del código. Cualquier aplicación que utilice FreeRTOS debe estar dividida en tres partes, dos correspondientes al sistema operativo y una correspondiente a la aplicación. El código de la aplicación interactúa con la capa del RTOS y es completamente independiente de los detalles específicos del puerto del dispositivo.

La capa de portabilidad del dispositivo es específica tanto para la placa como para el compilador utilizado, ya que parte de la funcionalidad requerida se implementa generalmente en código ensamblador y/o mecanismos específicos del compilador. Es importante entender esta estructura en capas, ya que FreeRTOS no admite la carga dinámica de aplicaciones. En su lugar, todo el código se compila en un solo proyecto y la aplicación, el RTOS y las capas del dispositivo se enlazan estáticamente.

Esta estructura en capas también es importante para configurar el entorno de compilación e interpretar el código de FreeRTOS una vez descargado. La distribución de FreeRTOS incluye todo el código actual específico del dispositivo y del compilador necesario para todas las placas compatibles. Este código se puede encontrar en el directorio "portable" de la descarga. El código del RTOS en sí se encuentra en la raíz del directorio "Source", con todos los encabezados necesarios para la aplicación en el directorio "include" [Organización de FreeRTOS].

La principal forma de seleccionar una placa y cargar aplicaciones es a través de la configuración del proyecto del compilador. Incluye el código correspondiente a la plataforma correcta con el código de implementación general del sistema operativo en el proyecto de compilación, junto con el código fuente de la aplicación, para crear una aplicación FreeRTOS. Dependiendo de la placa y las herramientas requeridas, esto puede tomar varias formas diferentes. Cada wiki específico de la placa incluye detalles sobre qué compiladores son compatibles y cómo se configura el proyecto. El wiki de cada placa compatible también incluye información de pedido para las placas de desarrollo utilizadas con la aplicación de ejemplo. Al realizar el pedido de la placa de desarrollo, asegúrate de que la cadena de herramientas seleccionada coincida con las herramientas utilizadas con la adaptación de FreeRTOS.

Al evaluar una placa candidata, es importante comprender la funcionalidad disponible en la adaptación para esa placa. Las adaptaciones oficiales incluyen la funcionalidad base de los primitivos y configuraciones del sistema operativo. Existen varias capacidades adicionales que pueden o no estar presentes en una placa en particular. Por ejemplo, algunas funciones de ahorro de energía que tienen diferentes niveles de soporte en las distintas placas. Parte de esta variación se debe a las funciones de hardware proporcionadas por los procesadores o placas de desarrollo. También existen algunas limitaciones, como el tamaño del código, impuestas por las herramientas seleccionadas para las adaptaciones. Revisa cuidadosamente las descripciones proporcionadas en la adaptación y la aplicación de ejemplo para comprender las capacidades y limitaciones de cada placa [Adaptaciones de FreeRTOS].

Una vez que se selecciona una placa, FreeRTOS proporciona varias opciones de configuración que deben explorarse y ajustarse al comportamiento requerido por la aplicación. Los ajustes se incluyen en el archivo FreeRTOSConfig.h proporcionado con la adaptación para la placa seleccionada. Esto requerirá cierto conocimiento de la placa y del diseño de software de la aplicación, por lo que puede haber cambios más adelante en el proceso si el diseño no se ha estabilizado por completo. A continuación, se enumeran algunos de los ajustes más importantes a considerar.

• configUSE_PREEMPTION: Esta bandera debe ser establecida y será necesaria para la mayoría de las aplicaciones en tiempo real. Esto habilita la preemption de tareas una vez que una tarea de mayor prioridad esté lista para ejecutarse. La alternativa es la multitarea cooperativa.
• configUSE_IDLE_HOOK y configUSE_TICK_HOOK: Estas configuraciones permiten adaptar la aplicación para el uso del tiempo ocioso (idle) y los relojes de software.
• configTICK_RATE_HZ: Esto determina con qué frecuencia se ejecutará el temporizador que activa el planificador.
• configMAX_PRIORITIES: Determina cuántas prioridades únicas se pueden asignar a las tareas en la aplicación.
• configUSE_TRACE_FACILITY y configCHECK_FOR_STACK_OVERFLOW: Estas configuraciones habilitan la funcionalidad de depuración y protección.
• configUSE_MUTEXES, configUSE_RECURSIVE_MUTEXES y configUSE_COUNTING_SEMAPHORES: Estas configuraciones habilitan los diferentes primitivos del sistema operativo.
• Hay varias API que se pueden utilizar en la aplicación y que se pueden configurar para ahorrar espacio. Si no se necesitan y el espacio es un problema, se pueden deshabilitar. Muchas de ellas están habilitadas de forma predeterminada.

Los sistemas en tiempo real y los sistemas por lotes (batch) son dos enfoques diferentes para procesar tareas, y presentan algunas diferencias clave:

1. Restricciones temporales: Los sistemas en tiempo real están sujetos a restricciones temporales estrictas, donde las tareas deben completarse dentro de plazos específicos. En contraste, los sistemas por lotes se ejecutan sin considerar plazos estrictos, y las tareas se procesan en lotes según la disponibilidad de recursos.

2. Interacción con el entorno: Los sistemas en tiempo real están diseñados para interactuar de manera activa y continua con su entorno. Los algoritmos en tiempo real responden a eventos y estímulos externos en tiempo real, tomando decisiones y realizando acciones inmediatas. En cambio, los sistemas por lotes no están diseñados para una interacción en tiempo real y se ejecutan en lotes, generalmente en segundo plano, sin una respuesta inmediata a eventos externos.

3. Planificación y priorización: En los sistemas en tiempo real, la planificación y la priorización son esenciales para garantizar el cumplimiento de las restricciones temporales. Los algoritmos en tiempo real deben asignar recursos y decidir el orden de ejecución de las tareas de manera óptima. Por otro lado, los sistemas por lotes se centran más en la eficiencia global y la utilización de los recursos, sin la necesidad de una planificación detallada para cumplir con plazos específicos.

4. Recolección de datos: En los sistemas de tiempo real se procesan los datos a medida que llegan, pero en los sistemas de procesamiento por lotes los datos se recopilan y agrupan en lotes antes de procesarlos. Esto permite acumular una cantidad significativa de datos antes de realizar el procesamiento.

5. Salidas de resultados. En los sistemas de procesamiento por lotes, se tiene un enfoque de otorgar resultados en forma de informes, archivos de salida o actualizaciones en bases de datos. Los resultados sirven para tomar decisiones empresariales, generar informes o alimentar otros sistemas.

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)

4. "Sistemas operativos de tiempo real, bastionado y funcionamiento". INCIBE-CERT. https://www.incibe-cert.es/blog/sistemas-operativos-tiempo-real-bastionado-y-funcionamiento (accedido el 25 de septiembre de 2022).

• Pratt, J. & Siewert, S. (2016). Real-Time Embedded Components and Systems with Linux and RTOS. MERCURY LEARNING and INFORMATION.

• EasyTask OS
• MaRTE OS
• FreeRTOS

Más acontinuación:

• 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 Archivado el 29 de julio de 2010 en Wayback Machine.
• DuinOS (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
• Milos
• OsaRTOS para PIC