Sistemas operativos en tiempo real (RTOS) y sus aplicaciones

Qué es el RTOS

Un sistema operativo en tiempo real (RTOS) es un sistema operativo ligero que se utiliza para facilitar la multitarea y la integración de tareas en diseños con recursos y tiempo limitados, como suele ocurrir en los sistemas integrados. Además, el término "tiempo real" indica previsibilidad/determinismo en el tiempo de ejecución más que velocidad bruta, por lo que normalmente se puede demostrar que un RTOS satisface los requisitos de tiempo real duro debido a su determinismo.

Los conceptos clave de los RTOS son:

Tarea

Las tareas (también podrían llamarse procesos/hilos) son funciones independientes que se ejecutan en bucles infinitos, normalmente cada una responsable de una función. Las tareas se ejecutan de forma independiente en su propio tiempo (aislamiento temporal) y pila de memoria (aislamiento espacial). El aislamiento espacial entre las tareas puede garantizarse con el uso de una unidad de protección de memoria por hardware (MPU), que restringe la región de memoria accesible y desencadena excepciones de fallo en caso de violación de acceso. Normalmente, los periféricos internos están mapeados en la memoria, por lo que se puede utilizar una MPU para restringir el acceso a los periféricos también.

Las tareas pueden estar en diferentes estados:

• Bloqueado: la tarea está esperando un evento (por ejemplo, tiempo de espera, disponibilidad de datos/recursos)
• Listo: la tarea está lista para ejecutarse en la CPU, pero no se está ejecutando porque la CPU está siendo utilizada por otra tarea
• En ejecución: la tarea está asignada para ser ejecutada en la CPU

Programador

Los programadores en el RTOS controlan qué tarea debe ejecutarse en la CPU y existen diferentes algoritmos de programación. Normalmente lo son:

• Preventivo: la ejecución de la tarea puede ser interrumpida si otra tarea con mayor prioridad está lista
• Cooperativo: el cambio de tarea solo se producirá si la tarea que se está ejecutando en ese momento se rinde

La programación preventiva permite que las tareas de mayor prioridad interrumpan a las de menor prioridad para cumplir con las restricciones de tiempo real, pero tiene el costo de una mayor sobrecarga en el cambio de contexto.

Comunicación entre tareas (ITC)

Normalmente, varias tareas tendrán que compartir información o eventos entre sí. La forma más sencilla de compartir es leer/escribir directamente las variables globales compartidas en la RAM, pero esto no es deseable debido al riesgo de corrupción de datos causado por una condición de carrera. Una mejor manera es leer/escribir variables estáticas de archivo accesibles por funciones setter y getter, y las condiciones de carrera pueden ser prevenidas deshabilitando las interrupciones o usando un objeto de exclusión mutua (mutex) dentro de la función setter/getter. La forma más limpia es utilizar objetos RTOS seguros para hilos, como la cola de mensajes, para pasar información entre tareas.

Además de compartir información, los objetos RTOS también son capaces de sincronizar la ejecución de tareas, ya que éstas pueden bloquearse para esperar la disponibilidad de los objetos RTOS. La mayoría de los RTOS 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 recurso
  • 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

Tic del sistema

Los RTOS necesitan una base de tiempo para medir el tiempo, normalmente en forma de una variable de contador de tics del sistema que se incrementa en una interrupción periódica del temporizador de hardware. Con el tic del sistema, una aplicación puede mantener más de un servicio basado en el tiempo (intervalo de ejecución de la tarea, tiempo de espera, corte de tiempo) utilizando un solo temporizador de hardware. Sin embargo, una tasa de tic más alta solo aumentará la resolución de la base de tiempo del RTOS, no hará que el software se ejecute más rápido.

Por qué usar RTOS

Organización

Las aplicaciones siempre pueden escribirse de forma de metal expuesto, pero a medida que aumenta la complejidad del código, tener algún tipo de estructura ayudará a gestionar las diferentes partes de la aplicación, manteniéndolas separadas. Además, con un modo de desarrollo estructurado y un lenguaje de diseño familiar, un nuevo miembro del equipo puede entender el código y empezar a contribuir más rápidamente. RFCOM Technologies ha desarrollado aplicaciones utilizando diferentes microcontroladores como Hercules de Texas Instruments, RL78 y RX de Renesas, y STM32 de STMicroelectronics en un RTOS diferente. Patrones de diseño similares nos permiten desarrollar aplicaciones en diferentes microcontroladores e incluso en un RTOS diferente.

Modularidad

Divide y vencerás. Al separar las funciones en diferentes tareas, se pueden añadir fácilmente nuevas funciones sin romper otras, siempre que la nueva función no sobrecargue los recursos compartidos, como la CPU y los periféricos. El desarrollo sin RTOS se encontrará normalmente en un gran bucle infinito en el que todas las funciones forman parte del bucle. Un cambio en cualquier característica dentro del bucle tendrá un impacto en otras características, lo que hace que el software sea difícil de modificar y mantener.

Pilas de comunicación y controladores

Muchos controladores o pilas adicionales como TCP/IP, USB, pilas BLE y bibliotecas gráficas se desarrollan/portan para/en los RTOS existentes. Un desarrollador de aplicaciones puede centrarse en una capa de aplicación del software y reducir el tiempo de comercialización de forma significativa.

Puntas

Asignación estática

El uso de la asignación estática de memoria para los objetos del RTOS significa reservar la pila de memoria en la RAM para cada objeto del RTOS durante el tiempo de compilación. Un ejemplo de función de asignación estática en freeRTOS es xTaskCreateStatic(). Esto asegura que un objeto RTOS puede ser creado con éxito, ahorrando la molestia de manejar una posible asignación fallida y haciendo la aplicación más determinista.

Para decidir el tamaño de la pila necesario para una tarea, ésta puede ejecutarse con un tamaño de pila mayor (más que suficiente) y luego se puede comprobar el uso de la pila en tiempo de ejecución para determinar la marca de agua alta. También existe una herramienta de análisis estático de la pila.

Capa de abstracción del sistema operativo (OSAL) y abstracción significativa

Al igual que la capa de abstracción del hardware (HAL), el uso de la capa de abstracción del RTOS permite que el software de aplicación migre fácilmente a otros RTOS. Las características de los RTOS son bastante similares, por lo que la creación de OSAL no debería ser demasiado complicada. Por ejemplo:

Usar directamente la API de freeRTOS:

if( xSemaphoreTake( spiMutex, ( TickType_t ) 10 ) == pdTRUE ) { //dosomething }

Envolver la API del RTOS en OSAL:

if( osalSemTake( spiMutex, 10 ) == true) { //dosomething }

utilizar la capa de abstracción en la comunicación entre tareas para hacer el código más legible y minimizar el alcance de un objeto RTOS:

if( isSpiReadyWithinMs( 10 ) ) { //doSomething }

Además, la abstracción también permite a un programador cambiar el objeto RTOS utilizado por debajo (por ejemplo, de mutex a semáforo de conteo) si hay más de un módulo SPI disponible. OSAL y otras capas de abstracción también ayudan en las pruebas de software al simplificar la inserción de funciones simuladas durante las pruebas unitarias.

Selección del intervalo de tictac

Lo ideal es que una tasa de tictac más baja sea mejor, ya que los gastos generales son menores. Para seleccionar una tasa de tics adecuada, el desarrollador puede enumerar las restricciones de tiempo de los módulos de una aplicación (intervalo de repetición, duración del tiempo de espera, etc.). Si hay algunos módulos atípicos que necesitan un intervalo pequeño, se puede considerar la posibilidad de tener una interrupción de temporizador dedicada para los módulos atípicos en lugar de aumentar la tasa de tics del RTOS. Si la función de alta frecuencia es muy corta (por ejemplo, escribir en un registro para encender o apagar un LED), puede hacerse dentro de una Rutina de Servicio de Interrupción (ISR), de lo contrario se puede utilizar el manejo diferido de la interrupción. El manejo de la interrupción diferida es una técnica para diferir el cálculo de la interrupción en una tarea del RTOS, el ISR sólo generará un evento a través del objeto del RTOS, entonces la tarea del RTOS será desbloqueada por el evento y hará el cálculo.

Supresión de garrapatas para aplicaciones de baja potencia

El ralentí sin tics desactiva la interrupción de tics cuando el sistema está en ralentí durante un tiempo prolongado. Una forma importante de que el firmware integrado reduzca el consumo de energía es poner el sistema en modo de bajo consumo durante el mayor tiempo posible. El ralentí sin tic se implementa desactivando la interrupción periódica del tic y configurando un temporizador de cuenta atrás para que interrumpa cuando una tarea bloqueada vaya a ejecutarse. Si no hay ninguna tarea en espera de un tiempo de espera, la interrupción de tic puede desactivarse indefinidamente hasta que se produzca otra interrupción (por ejemplo, la pulsación de un botón). Por ejemplo, en el caso de una baliza Bluetooth de baja energía (BLE), la MCU puede ponerse en reposo profundo entre el intervalo de publicidad. Como se muestra en la figura 1, la baliza se pone en modo de reposo profundo durante la mayor parte del tiempo, consumiendo energía en decenas de µA.

Figura 1: Consumo de corriente de una baliza BLE (Fuente de la imagen: RFCOM)

Conclusión:

Un RTOS proporciona características como planificador, tareas y objetos RTOS de comunicación entre tareas, así como pilas de comunicación y controladores. Permite a los desarrolladores centrarse en la capa de aplicación del software embebido y diseñar software multitarea con facilidad y rapidez. Sin embargo, al igual que cualquier otra herramienta, hay que utilizarla adecuadamente para que aporte más valor. Para crear un software embebido seguro y eficiente, los desarrolladores deben saber cuándo utilizar las características del RTOS y también cómo configurarlo.