1. Introducción a los RTOS
1.1. ¿Qué es un RTOS?
Un RTOS (Real-Time Operating System o Sistema Operativo en Tiempo Real) es un sistema operativo diseñado para ejecutar tareas con tiempos de respuesta predecibles, cumpliendo estrictamente con los plazos establecidos (deadlines). Se utiliza principalmente en sistemas embebidos donde la precisión y rapidez son factores críticos.
Características principales:
Multitarea con planificación basada en prioridades: garantiza que las tareas más importantes se ejecuten primero.
Respuesta rápida y predecible a eventos externos: esencial en entornos críticos.
Manejo eficiente de interrupciones: permite reaccionar en tiempo real a cambios en el sistema.
Baja latencia en el cambio de contexto: minimiza los retrasos al alternar entre tareas.
Ejemplos de aplicaciones:
Los RTOS se encuentran en controladores industriales, sistemas automotrices y dispositivos médicos, donde un fallo en los tiempos podría tener consecuencias graves.
En comparación con los sistemas operativos de propósito general, un RTOS es más ligero y compacto. Su diseño está enfocado en optimizar el uso de recursos y garantizar la predictibilidad en la ejecución de tareas.
1.2. Procesos y Hilos
En sistemas operativos de propósito general como Linux o Windows:
Proceso: es un programa que se ejecuta de forma independiente, con su propia memoria aislada.
Ejemplo: Abrir un navegador y un editor de texto crea dos procesos separados.Hilo: es una unidad de ejecución dentro de un proceso que comparte la misma memoria con otros hilos de ese proceso.
Ejemplo: En un navegador, un hilo puede cargar una página web mientras otro reproduce un video.
Un sistema operativo capaz de ejecutar múltiples hilos simultáneamente se considera multitarea (multitask).
En un RTOS, no se hace distinción entre procesos e hilos. Todo se maneja como tareas que comparten el mismo espacio de memoria.
¿Por qué esta diferencia?
La prioridad en un RTOS es la eficiencia y la predictibilidad. Separar la memoria, como se hace con procesos, introduce una sobrecarga adicional y aumenta el tiempo de cambio de contexto (context switch). Esto resulta incompatible con las estrictas necesidades de tiempo real que requieren tiempos de respuesta mínimos y predecibles.
2. Conceptos Fundamentales de RTOS
2.1. Tareas y Co-rutinas
En FreeRTOS, una aplicación puede diseñarse utilizando únicamente tareas, únicamente co-rutinas o una combinación de ambas. Aunque ambas opciones son útiles, existen diferencias importantes que deben tenerse en cuenta al elegir cuál utilizar.
Diferencias entre Tareas y Co-rutinas
Tareas: Utilizan una API específica y son ideales para sistemas con suficiente memoria. Ofrecen mayor flexibilidad y compatibilidad con otras funcionalidades del sistema operativo, como colas y semáforos.
Co-rutinas: Están diseñadas para procesadores con limitaciones severas de RAM, ya que son más ligeras que las tareas. Sin embargo, tienen una API diferente que no permite compartir directamente recursos como colas o semáforos con las tareas.
En sistemas con memoria suficiente, se recomienda usar exclusivamente tareas debido a su mayor versatilidad. Las co-rutinas solo deberían considerarse en sistemas muy limitados en cuanto a RAM.
2.2. Estados de una Tarea (Task States)
En FreeRTOS, las tareas pueden estar en uno de los siguientes estados según su situación actual y las condiciones del sistema. Estos estados son fundamentales para entender cómo se gestionan las tareas dentro del sistema operativo.
1. Running (Ejecutándose)
Este es el estado en el que la tarea está utilizando activamente el procesador.
En un sistema con un único núcleo, solo puede haber una tarea en este estado.
En sistemas multinúcleo, puede haber una tarea en ejecución por cada núcleo.
2. Ready (Listo)
Una tarea en este estado está preparada para ejecutarse pero no puede hacerlo porque otra tarea de igual o mayor prioridad está siendo ejecutada.
Estas tareas están en la cola de planificación, esperando que el sistema operativo les asigne tiempo de CPU.
3. Blocked (Bloqueado)
Una tarea en este estado está esperando que ocurra un evento específico, como la expiración de un temporizador, la recepción de datos o una señal externa.
Mientras está bloqueada, no consume tiempo de CPU.
El sistema operativo desbloquea automáticamente la tarea cuando se cumple la condición de espera, devolviéndola al estado "Ready".
4. Suspended (Suspendido)
Una tarea en estado suspendido no se ejecutará ni siquiera si están disponibles los recursos que necesita.
La principal diferencia con el estado bloqueado es que no depende de ningún evento temporal para salir de este estado.
La transición a este estado (y la salida de él) se realiza exclusivamente mediante las funciones vTaskSuspend() y xTaskResume(). Esto permite al programador suspender manualmente una tarea y reanudarla cuando sea necesario.
Relación entre Estados
El sistema operativo FreeRTOS utiliza un planificador para mover las tareas entre estos estados según las condiciones actuales del sistema.
Por ejemplo:
Una tarea pasa de "Ready" a "Running" cuando el procesador está disponible.
Pasa de "Running" a "Blocked" cuando debe esperar un evento.
Puede pasar a "Suspended" si el programador decide detener su ejecución temporalmente.
Transiciones válidas del estado de la tarea . Fuente: freertos.com
2.3. Prioridades de Tareas
En FreeRTOS, las tareas tienen asignada una prioridad numérica que determina su importancia en el sistema. El planificador se asegura de que la tarea con mayor prioridad entre las que están listas sea la que obtenga tiempo de CPU.
Asignación de Prioridades en FreeRTOS
Las prioridades se asignan numéricamente, donde los valores más bajos indican prioridades bajas.
Por ejemplo, la tarea inactiva (idle task) siempre tiene prioridad 0, la más baja del sistema.
El rango de prioridades va de 0 a (configMAX_PRIORITIES - 1), donde configMAX_PRIORITIES se define en el archivo FreeRTOSConfig.h.
El valor máximo permitido para configMAX_PRIORITIES es 32, pero definir un valor menor puede ahorrar memoria RAM, ya que cada nivel de prioridad requiere espacio adicional en las estructuras internas de FreeRTOS.
Asignación de Prioridades en μITRON
A diferencia de FreeRTOS, μITRON utiliza una convención opuesta:
Los valores más bajos representan prioridades más altas.
La prioridad 0 se reserva para tareas críticas, mientras que las prioridades más altas (valores numéricos mayores) se asignan a tareas menos importantes.
En sistemas como los basados en Renesas, la tarea inactiva de μITRON tiene una prioridad de 15, que es la más baja.
Regla Clave sobre Ejecución
En cualquier momento, la tarea que se encuentra en estado "Ejecutándose" es siempre la de mayor prioridad entre las que están listas para ejecutarse. Si una tarea con una prioridad más alta pasa al estado "Listo", el planificador interrumpirá la tarea actual y asignará inmediatamente tiempo de CPU a la de mayor prioridad.
Nota Importante
Al diseñar un sistema con FreeRTOS, es crucial establecer prioridades adecuadas para evitar problemas como:
Starvation (inanición): Tareas de baja prioridad que nunca se ejecutan debido a tareas de alta prioridad constantemente listas.
Inversión de prioridades: Cuando una tarea de alta prioridad depende de una tarea de baja prioridad que está siendo bloqueada por otra de prioridad intermedia.
Fuente: freertos.com
2.4. Scheduling (Planificación)
El scheduler o planificador es una parte esencial del kernel del RTOS. Su tarea principal es decidir qué tarea debe ejecutarse en cada momento, garantizando una ejecución eficiente y respetando las prioridades establecidas por el desarrollador. Durante la vida de una tarea, el scheduler puede pausarla y reanudarla varias veces para gestionar la ejecución de otras tareas.
En un RTOS como FreeRTOS, es fundamental que la planificación garantice que las fechas límite estrictas (deadlines) de los eventos del mundo real se cumplan. Para lograr esto:
Cada tarea recibe una prioridad asignada por el desarrollador.
El scheduler se asegura de que la tarea de mayor prioridad que esté lista para ejecutarse obtenga el tiempo de CPU necesario.
Importancia de Gestionar Tareas de Alta Prioridad
En FreeRTOS, siempre se ejecuta la tarea de mayor prioridad que esté lista para ejecutarse. Esto puede generar un problema si una tarea de alta prioridad nunca entra en estado "bloqueado" o "suspendido", ya que estaría constantemente utilizando el procesador y privando de tiempo de ejecución a las tareas de menor prioridad.
Para evitar esto, es preferible que las tareas de alta prioridad que esperan un evento (como una conexión o desconexión) entren en estado "bloqueado" mediante una llamada al kernel que las suspenda hasta que ocurra el evento. Esto se logra utilizando interrupciones o señales externas.
Mientras la tarea de alta prioridad está bloqueada, las tareas de menor prioridad pueden ejecutarse, maximizando el uso eficiente del sistema.
2.5. Planificación en FreeRTOS vs planificación en μITRON
En FreeRTOS, el algoritmo utilizado es Round-Robin, combinado con planificación basada en prioridades. Las reglas principales son:
Las tareas de la misma prioridad comparten el tiempo de CPU de manera equitativa.
Cada tarea tiene un tiempo fijo para ejecutarse, conocido como quantum.
Si una tarea no finaliza dentro de su quantum, el scheduler la pausa y la coloca al final de la cola, permitiendo que las demás tareas se ejecuten.
Esto permite una ejecución más justa y fluida entre tareas de la misma prioridad.
En μITRON, se utiliza el algoritmo First-Come, First-Served (FCFS), que sigue estas reglas:
Las tareas se ejecutan en el orden en que llegan.
Una tarea se completa completamente antes de pasar a la siguiente.
Este enfoque es sencillo, pero tiene desventajas. Si una tarea es demasiado larga, puede causar retrasos significativos en la ejecución de otras tareas que están esperando en la cola. Es adecuado para sistemas donde las tareas tienen tiempos de ejecución predecibles y no se requiere una alta complejidad en la planificación.
2.6. Mutex, Semáforo e Interrupciones: Diferencias, Ventajas y Desventajas
Tareas en RTOS
En un RTOS, una tarea es una función escrita en C que tiene características particulares: no devuelve nada, toma un único argumento y nunca termina. Es gestionada exclusivamente por el sistema operativo, que se encarga de programar su ejecución y estado.
Para representar un ciclo infinito dentro de una tarea, se suelen usar bucles como while(1) o for(;;). Ambas opciones son equivalentes y su elección depende del gusto del programador.
En sistemas basados en Renesas M3, hay funciones clave que permiten manejar las tareas:
slp_tsk: Suspende una tarea, liberando la CPU para que otras tareas puedan ejecutarse.
tslp_tsk: Similar a slp_tsk, pero con un tiempo definido en milisegundos.
wup_tsk: Despierta una tarea previamente suspendida.
En el caso de μITRON, las tareas generalmente se definen de forma estática durante la configuración del sistema. Sin embargo, algunas implementaciones también admiten su creación dinámica. Cada tarea necesita dos elementos principales:
Una pila: Aquí se almacenan variables locales, parámetros de funciones y direcciones de retorno.
Un bloque de control de tareas (TCB): Este bloque guarda el estado actual de la tarea cuando es suspendida, lo que permite que se reanude desde el punto exacto en que se detuvo.
Conceptos Fundamentales
En sistemas concurrentes, existen varios conceptos importantes que determinan cómo se manejan los recursos y las tareas:
Exclusión mutua: Significa que un recurso compartido solo puede ser usado por una tarea o proceso a la vez. Por ejemplo, una impresora solo puede ser utilizada por un usuario en un momento dado.
Bloqueo mutuo: Ocurre cuando un proceso no libera un recurso mientras espera otro. Por ejemplo, si un proceso tiene un recurso A y otro tiene el recurso B, pero ambos necesitan el recurso del otro para continuar, se produce un bloqueo.
Deadlock (interbloqueo): Se da cuando varios procesos quedan bloqueados indefinidamente porque cada uno está esperando un recurso retenido por otro. Esto suele ocurrir cuando hay exclusión mutua, retención y espera, no expropiación de recursos y una espera circular.
Starvation (inanición): Un proceso no accede a recursos porque otros de mayor prioridad lo superan constantemente, dejándolo sin ejecutar.
Inversión de prioridades: Una tarea de alta prioridad queda bloqueada por una de baja porque ambas necesitan un recurso que una tercera tarea (de prioridad intermedia) está utilizando.
Mutex
Un mutex (abreviatura de exclusión mutua) es un objeto de sincronización que garantiza que solo una tarea acceda a un recurso compartido a la vez. Antes de utilizar un recurso, una tarea debe "bloquear" el mutex, y una vez que termina, debe "desbloquearlo". Si el mutex ya está bloqueado, la tarea que lo necesita entra en un estado de espera (Blocked).
El uso de un mutex tiene varias ventajas, como la herencia de prioridad, que eleva temporalmente la prioridad de una tarea de baja prioridad si una tarea de mayor prioridad necesita acceder al mismo recurso. Esto evita el problema de inversión de prioridades.
Por ejemplo, al compartir una UART para imprimir mensajes, el uso de un mutex asegura que los mensajes no se mezclen, permitiendo que cada tarea imprima de forma ordenada.
Semáforo
Un semáforo es una variable que controla el acceso a recursos compartidos. Existen dos tipos principales:
Semáforo binario: Permite acceso a un solo recurso, similar a un mutex pero sin herencia de prioridad.
Semáforo contador: Controla el acceso a múltiples instancias de un recurso, como un número limitado de conexiones de red.
Las operaciones principales de un semáforo son:
wait(): Decrementa el contador del semáforo. Si su valor es 0, la tarea debe esperar.
signal(): Incrementa el contador, indicando que un recurso ha sido liberado.
Interrupciones
Las interrupciones son mecanismos que permiten pausar la ejecución de una tarea para atender eventos urgentes. En sistemas como el Renesas R-IN32M3, hay dos tipos de interrupciones:
Interrupciones de kernel: Gestionadas por el sistema operativo, permiten realizar llamadas de servicio, pero tienen menor prioridad.
Interrupciones no kernel: No dependen del sistema operativo, ofreciendo una respuesta más rápida pero sin soporte para llamadas de servicio.
Un ejemplo práctico es el manejo de eventos SYNC en EtherCAT, donde una interrupción activa la tarea responsable de procesar el evento.
Diferencias entre Mutex y Semáforo
Conclusión
Mutex, semáforos e interrupciones son herramientas esenciales en la programación concurrente de sistemas en tiempo real. Elegir la herramienta adecuada depende del tipo de recurso, el nivel de acceso requerido y las necesidades de sincronización del sistema. Usarlas correctamente garantiza sistemas más eficientes y predecibles, evitando conflictos entre tareas y optimizando el rendimiento.
2.7. Cola de datos
Una cola de datos es un mecanismo que permite a dos tareas comunicarse entre sí mediante el envío y recepción de mensajes simples, también conocidos como elementos de datos. Cada cola tiene un identificador único y un espacio de almacenamiento para los datos enviados.
Funcionamiento Básico
Si una tarea quiere enviar un dato pero no hay espacio disponible en la cola, espera hasta que haya lugar.
Si una tarea quiere recibir un dato pero la cola está vacía, espera hasta que llegue un dato.
En casos donde la cola tiene capacidad cero, el envío y la recepción son instantáneos. Esto significa que las tareas se sincronizan directamente para intercambiar el dato, eliminando la necesidad de almacenamiento intermedio.
Los datos enviados pueden ser números, estructuras o direcciones de memoria compartida. FreeRTOS asegura que estos datos se copien del remitente al receptor.
Colas en FreeRTOS
En FreeRTOS, puedes crear tantas colas como necesite tu aplicación. Cada cola se crea con la función xQueueCreate() y es un objeto independiente con su propio almacenamiento y estado.
Algunos ejemplos comunes de uso de colas en FreeRTOS son:
Enviar comandos de una tarea a otra.
Recibir datos de sensores.
Enviar registros de depuración a una tarea encargada de procesarlos.
El número de colas que puedes crear está limitado únicamente por la memoria disponible en tu sistema. Cada cola ocupa memoria dependiendo del tamaño de los datos y la cantidad máxima de elementos que puede almacenar.
Diferencias entre Cola y Pila
Las colas y pilas son estructuras de datos fundamentales, pero su comportamiento es diferente:
Colas por Copia vs. Referencia
En FreeRTOS, las colas generalmente trabajan mediante copia de los datos enviados. Sin embargo, también es posible utilizar colas por referencia (enviar punteros en lugar de datos). FreeRTOS prefiere el método de copia por considerarlo más flexible y simple. Algunas razones para esto son:
Flexibilidad: Aunque FreeRTOS copia los datos en la cola, también permite enviar punteros en lugar de datos cuando el tamaño de los elementos es demasiado grande.
Uso de Variables de Pila: Es posible enviar una variable local a una cola, incluso si la variable no existirá después de que la función emisora termine.
Desacoplamiento: La tarea emisora y receptora están completamente desacopladas, lo que significa que el desarrollador no tiene que preocuparse por el estado de la tarea que recibe o envía los datos.
Reutilización de Buffers: La tarea emisora puede reutilizar la variable o el búfer inmediatamente después de enviarlo a la cola.
2.8. Idle Task (Tarea Inactiva) en FreeRTOS
En FreeRTOS, la tarea inactiva es una tarea especial creada automáticamente por el sistema cuando el scheduler inicia. Su objetivo es garantizar que siempre haya una tarea ejecutándose, incluso cuando no hay trabajo pendiente.
Características principales:
Es creada automáticamente por el sistema operativo.
Se ejecuta cada vez que no hay otras tareas listas para correr.
Tiene la prioridad más baja del sistema.
Libera memoria de tareas eliminadas (en FreeRTOS mediante la función vTaskDelete, en iTron no se usa para esto).
Puede configurarse para poner al microcontrolador en un modo de bajo consumo durante períodos de inactividad.
Nota: La tarea inactiva no debe bloquearse, ya que es esencial para el correcto funcionamiento del scheduler.
Representacion de cómo se programarían las tareas mediante un sistema operativo en tiempo real.Fuente: freertos.org
Se puede implementar funcionalidades de la idle task a nivel de aplicación haciendole un “idle hook” ó “idle callback”. Sin embargo se debe cumplir siempre con:
una función idle task hook nunca debe intentar bloaquearse o suspenderse por si misma. (bloquear la idle task en cualquier forma causaría un escenario en donde ninguna tarea sería capaz de entrar en “running state”).
2.9. Tick Interrupt
Medición del Tiempo y la Interrupción Tick
En sistemas de tiempo real, la medición precisa del tiempo es esencial para coordinar tareas, manejar eventos y cumplir con las fechas límite (deadlines). Este sistema de administración de tiempo depende de una interrupción periódica conocida como tick interrupt, que actualiza el contador interno del sistema a intervalos regulares.
Medición de Tiempo en RTOS
El tiempo se inicializa en 0 cuando el sistema comienza su ejecución.
Cada vez que ocurre una interrupción de tick, el contador interno del sistema se actualiza. En sistemas compatibles con μITRON 4, esta funcionalidad es manejada por la llamada a la función isig_tim, que incrementa el contador en cada interrupción.
Compatibilidad con μITRON
μITRON 4 soporta la medición de tiempo mediante isig_tim. Esta función es clave para actualizar el contador de tiempo del sistema y garantizar que las operaciones temporizadas se realicen correctamente.
Sin embargo, en el sistema Renesas R-IN32M3, isig_tim no es soportado, lo que limita la posibilidad de implementar ciertas funciones relacionadas con el tiempo directamente en este hardware.
Fuente: freertos.com
2.10. Dispatch
El dispatch es el proceso en un sistema operativo en tiempo real (RTOS) mediante el cual el procesador cambia el contexto de ejecución de una tarea (task) a otra. Este mecanismo es crucial para permitir que múltiples tareas compartan el procesador de manera eficiente, respetando las prioridades y los tiempos críticos definidos en el sistema.
El proceso de dispatch incluye los siguientes pasos:
Guardar el contexto de la tarea actual: Esto incluye los registros, la pila, el contador de programa y cualquier otro dato necesario para que la tarea pueda reanudarse más tarde exactamente desde donde se detuvo.
Restaurar el contexto de la siguiente tarea: La tarea seleccionada por el planificador (scheduler) recupera su estado previo de ejecución.
Transferir el control del CPU: El procesador comienza a ejecutar la nueva tarea, asegurando que el sistema continúe funcionando de manera fluida y eficiente.
Diferencia entre Scheduler y Dispatcher
El scheduler decide qué tarea debe ejecutarse a continuación, basándose en prioridades y estados.
El dispatcher se encarga de realizar el cambio de contexto y transferir el control del CPU a la tarea seleccionada por el scheduler.
Este mecanismo es esencial en un RTOS para garantizar que se respeten las prioridades y que los eventos críticos se gestionen de manera oportuna.
“Dispatch” – Fuente: renesas.com
La imagen anterior es un ejemplo de como el HW-RTOS (de Renesas) maneja las interrupciones y el cambio entre dos tareas en el CPU.
Task_A se está ejecutando.
Llega una interrupción
El sistema operativo activa ISR (Interrupt Service Routine) que se encarga de identificar la interrupción y a que API (Application Programming Interface) corresponde atenderla.
Se ejecuta la API asociada a esta interrupción anterior.
El sistema operativo realiza el “Dispatch”, que es el proceso de cambiar la ejecución de una Task por otra en el CPU
2.11. Hook
En μITRON, un hook es una función definida por el usuario que el sistema operativo invoca automáticamente en respuesta a eventos específicos. Los hooks permiten personalizar y extender el comportamiento del sistema operativo sin necesidad de modificar su núcleo, lo que facilita la adaptación a las necesidades particulares de cada aplicación.
Ejemplos Comunes de Hooks en μITRON
Startup Hook
Se ejecuta durante la inicialización del sistema, antes de que las tareas del usuario comiencen a ejecutarse.
Es útil para configurar hardware o inicializar variables globales necesarias para el funcionamiento de la aplicación.
Idle Hook
Se invoca cuando no hay tareas listas para ejecutarse, es decir, cuando el sistema está en estado de inactividad.
Ideal para implementar modos de bajo consumo energético o realizar tareas de mantenimiento no críticas.
Task Termination Hook
Se activa automáticamente cuando una tarea termina o es eliminada.
Permite liberar recursos asociados con la tarea, como memoria dinámica o identificadores de recursos, y realizar cualquier acción de limpieza necesaria.
Interrupt Entry/Exit Hook
Algunas implementaciones de μITRON permiten definir funciones que se ejecutan al entrar o salir de una interrupción.
Es útil para medir la latencia de las interrupciones, registrar estadísticas o realizar tareas de monitoreo.
Error Hook
Se ejecuta cuando ocurre un error en el sistema, como la falla en una llamada al sistema debido a la falta de recursos.
Permite manejar estos eventos, registrar información para depuración o realizar acciones correctivas.
Beneficios de Utilizar Hooks en μITRON
Personalización: Facilitan la adaptación del sistema operativo a los requisitos específicos de cada aplicación, sin modificar el núcleo del sistema.
Mantenimiento: Ayudan a realizar tareas como la liberación de recursos, la gestión de errores o el registro de eventos críticos para depuración.
Eficiencia: Permiten implementar estrategias de ahorro energético, optimizar el rendimiento del sistema y realizar tareas auxiliares en momentos oportunos.