Toda la verdad sobre RTOS de Colin Walls

Toda la verdad sobre RTOS. Artículo # 1.

Sistemas operativos en tiempo real: introducción

Esta serie de artículos está dedicada a un estudio exhaustivo de todos los aspectos de los sistemas operativos en tiempo real (RTOS). Los artículos están dirigidos a desarrolladores que tienen curiosidad por saber cómo funciona RTOS y cómo usarlos. El punto de partida será la discusión sobre los sistemas de tiempo real en general, y luego hablaremos sobre cómo RTOS puede simplificar su implementación y hacer que el código resultante sea más confiable.

Mirando dentro del RTOS, veremos cómo funciona el programador de tareas. Gracias al subprocesamiento múltiple, parece que la CPU realiza varias operaciones al mismo tiempo. Esto no es mágico, una comprensión de los principios del programador de tareas está disponible incluso para un ingeniero de software sin experiencia. Hablaremos sobre otros objetos del RTOS: sobre la interacción entre tareas y sincronización, sobre el modo en tiempo real, sobre la gestión de la memoria, etc. Todo será descrito con precisión y respaldado por ejemplos de código.

Para el desarrollador, un aspecto clave de RTOS es la API, un conjunto de llamadas a procedimientos que proporcionan acceso a la funcionalidad RTOS. La serie presentará artículos sobre cómo funciona la API, qué estándares están disponibles y cómo pasar de una API a otra.

A continuación hay una lista de temas que consideraremos en el futuro cercano:

• Estructura del programa y tiempo real.
• Sistemas operativos en tiempo real
• Tareas y planificación
• Interacción de tareas y sincronización
• Otros servicios del sistema operativo
• Núcleo SE
• Planificador
• Las tareas
• Secciones de memoria
• Señales
• Grupos de banderas de eventos
• Semáforos
• Buzones
• Colas
• Canales
• Hora del sistema
• Temporizadores de software
• Interrupciones
• Diagnóstico y comprobación de errores.
• Inicialización y Lanzamiento

La serie de artículos no está vinculada a ningún sistema operativo en tiempo real en particular; la mayor parte del material es aplicable a las opciones disponibles públicamente para implementar RTOS. Según el autor, el uso de un sistema operativo comercial listo para usar con soporte existente es la forma más confiable y productiva de trabajar. Uno de los artículos estará dedicado a una discusión detallada sobre el tema de "hacer vs comprar" y otras metodologías para elegir un RTOS.

Sin embargo, para explicar el diseño interno del RTOS, se utilizan ejemplos del código real del producto, Nucleus SE.

Fuente: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

Toda la verdad sobre RTOS. Articulo # 2

RTOS: estructura y modo en tiempo real
Estructura del programa y tiempo real.

Esta serie de artículos trata sobre sistemas integrados y, en particular, sobre software que se ejecuta en sistemas integrados. Comencemos con la definición. ¿Qué es un sistema embebido? En 1986, cuando escribí el primer libro sobre este tema, ese término no existía. Se utilizaron los conceptos de "sistema dedicado" o "microsistema", pero, por supuesto, no reflejaban toda la esencia. Unos años más tarde, la palabra "incorporado" entró en uso, y todos los especialistas comenzaron a usarla activamente.

Volver a la definición de un sistema embebido. En un intento de explicar a mis amigos y familiares en qué estoy trabajando, se me ocurrió la siguiente explicación: un sistema integrado es cualquier dispositivo electrónico que tiene un procesador, pero que generalmente no se acepta como computadora.

El sistema operativo (SO) siempre está en la computadora; En los sistemas embebidos modernos, solo se utilizan algunos tipos de SO. A pesar de que el uso del kernel prevalece en los sistemas de alto rendimiento (32 y 64 bits), es posible beneficiarse de su uso en dispositivos de baja potencia. El enfoque de estos artículos está en los sistemas operativos, tanto en general como con implementación específica.

¿Por qué usar el sistema operativo?

Veamos por qué los sistemas operativos se usan en principio. Hay muchas explicaciones, algunas de ellas dependen tanto del factor humano como de las características técnicas. Recuerdo la historia En una de nuestras oficinas había un rincón de la cocina donde se podía hacer café. En la puerta había un cartel con la inscripción: "Por favor, no cierre la puerta". Debajo, alguien escribió: "¿Por qué no?", A lo que otra persona respondió: "Porque". Una versión muy abreviada de la frase "porque le estamos diciendo que haga exactamente eso". Por las mismas razones, los sistemas operativos se utilizan en algunos sistemas, simplemente porque es necesario hacerlo.

Otra explicación es el uso de aplicaciones de escritorio. ¿Por dónde empiezas si escribes software para PC o Mac? Enciende la computadora, inicia Windows / Linux o macOS y comienza a programar. Tener un sistema operativo es una condición dada, y proporciona una serie de servicios útiles. Es poco probable que decida comenzar desde cero al programar el metal desnudo. Por lo tanto, no es sorprendente si un ingeniero que tiene experiencia en la escritura de software, pero para quien el firmware es nuevo, dependerá de la presencia de un sistema operativo en el sistema que desarrolla.

Vale la pena señalar que un aspecto clave del sistema operativo de escritorio que los usuarios conocen es la interfaz de usuario (UI). Pregúntele a alguien qué es Windows y responderá que son ventanas, menús, cuadros de diálogo, iconos, pero el sistema de archivos, la comunicación entre programas y la capacidad de interactuar con otros sistemas apenas se mencionan. Esta es la principal diferencia entre el escritorio y el sistema embebido: este último puede no tener una interfaz de usuario, y si lo es, es bastante sencillo. Esta es la primera de muchas diferencias clave:

• Un sistema integrado generalmente ejecuta una sola aplicación de software desde el encendido hasta el apagado.
• Los sistemas integrados tienen recursos limitados. La cantidad de memoria puede ser bastante grande, pero no el hecho de que pueda expandirse; El procesador tiene una potencia limitada.
• Muchas aplicaciones integradas funcionan en tiempo real. Más sobre esto en el artículo a continuación.
• Las herramientas de desarrollo de firmware están especializadas y se ejecutan en la computadora host (como una PC) y no en el sistema de destino.
• La actualización del firmware es un proceso complejo. A pesar de las oportunidades que aparecen debido a los dispositivos conectados, las actualizaciones de firmware durante la operación aún no son la norma (a diferencia de las actualizaciones y parches (parches) regulares utilizados para el software de escritorio).

Antes de considerar cómo estructurar aplicaciones integradas, comprenderemos los conceptos utilizados en las computadoras para ejecutar programas que utilizan el sistema operativo.

En primer lugar, hay una ejecución de programas al estilo DOS, cuando los programas se ejecutan alternativamente.



Cada programa se inicia, implementa y finaliza. Usamos, digamos, el programa 1, luego el programa 2, luego quizás tomamos un descanso, pasamos al programa 3 y luego volvemos al programa 2. El segundo uso del programa 2 comienza de nuevo: el lanzamiento no comienza desde donde lo dejamos. esto (excepto en los casos en que la aplicación en sí no brinde tal oportunidad).

Después de DOS, las cosas se complicaron un poco, ya que Windows se ha convertido en algo común. Ejecutar programas al estilo de Windows significa ejecutar múltiples programas en modo multiproceso.



En este modo, parece que los programas se están ejecutando al mismo tiempo, y Windows está controlando esta ilusión. Primero, se inicia el programa 1, luego al mismo tiempo se inicia el programa 2, luego el programa 3. El programa 2 finaliza, los programas 1 y 3 aún se están ejecutando. El programa 3 finaliza, solo queda el programa 1. Más tarde, el programa 2 se reanuda y el programa 1 finaliza, solo queda el programa 2. Este es un curso realista de eventos cuando Windows es utilizado por un usuario común. El sistema operativo asigna recursos para que todos los programas utilicen correctamente el procesador. También proporciona una comunicación fácil entre programas (por ejemplo, portapapeles) y controla la interfaz de usuario.

Algunos dispositivos portátiles requieren más flexibilidad que la que puede ofrecer DOS, pero dados los recursos limitados, se requieren gastos generales más bajos que Windows. Como resultado, tenemos la ejecución de programas al estilo de iOS, a saber:



Los programas se inician uno a la vez, pero su estado se guarda automáticamente para que pueda continuar desde el mismo lugar al cerrar. Por ejemplo, el programa 1 se inicia, luego se detiene para usar el programa 2, luego, por ejemplo, el dispositivo se apaga por un momento. Al reanudar, se carga el programa 3 (el estado del programa 2 se guardó automáticamente) y luego el usuario vuelve al programa 2 y continúa trabajando en él. Entiendo que el modelo de ejecución de una aplicación iOS es mucho más complicado que el descrito anteriormente, sin embargo, esta descripción es solo un breve resumen de la percepción inicial del usuario.

La mayoría de las aplicaciones integradas no coinciden con ninguno de los modelos anteriores. Como regla general, el dispositivo inicia el programa cuando se enciende la alimentación y continúa funcionando solo con este software durante un período de tiempo indefinido. La estructura de dicho código debe ser cuidadosamente pensada.

Modelos de firmware

Los sistemas de escritorio son casi todos iguales. Desde el punto de vista del programa de aplicación, todas las computadoras personales con Windows son idénticas. Los sistemas integrados son únicos: cada uno es diferente de los demás. Las diferencias pueden ser técnicas: tipo de procesador, tamaño de memoria, número de dispositivos periféricos. Los aspectos prioritarios de las aplicaciones también pueden diferir en velocidad, consumo de energía, seguridad y confiabilidad. Puede haber diferencias comerciales que afectan los precios: los volúmenes de producción y la elección entre hardware personalizado o estándar.

Estas diferencias son importantes para los desarrolladores integrados. Por ejemplo, la elección de herramientas de desarrollo (compiladores, depuradores, etc.) depende del tipo de procesador. Muchos factores influyen en la elección del sistema operativo o incluso en la decisión de aplicarlo en principio. La estructura del software (modelo de software) debe seleccionarse cuidadosamente para cada aplicación integrada individual.

Dependiendo de los requisitos de la aplicación, el software integrado puede tener varias estructuras de diferentes niveles de complejidad, por ejemplo:



La forma más simple es una estructura cerrada en la que se repite la misma secuencia de acciones. Si la aplicación es lo suficientemente simple como para que pueda implementarse de esta manera, esto es ideal: el código simple es confiable y comprensible. Sin embargo, dicha estructura es extremadamente sensible a la parte del código que puede tomar demasiado tiempo del procesador, es decir, algunos comandos se ejecutan durante tanto tiempo que retrasan la ejecución de otras tareas de la aplicación. Además, este modelo no escala bien: mejorar el código puede ser un problema, porque los complementos pueden afectar el rendimiento del código antiguo.

Si se requiere algo más complicado, puede intentar colocar una parte no crítica del código en el bucle principal y una parte sensible al tiempo en el controlador de interrupciones (Rutinas de servicio de interrupción, ISR). Las acciones del controlador de interrupciones son básicamente bastante cortas, realizan solo tareas críticas y marcan secciones del bucle principal para completar el trabajo lo antes posible. Pueden surgir dificultades cuando es necesario distribuir el trabajo entre el bucle principal y el controlador de interrupciones (así como entre varios desarrolladores).

Para obtener la máxima flexibilidad de la aplicación, será necesario dividirlo en varios programas independientes y relativamente independientes (llamémoslos tareas o subprocesos), que se ejecutarán en modo multiproceso. También se pueden incluir pequeños controladores de interrupción en el sistema, pero notificarán principalmente las tareas o desencadenarán una acción. Para lograr esto, necesita un sistema operativo, o al menos un núcleo. El uso de subprocesos múltiples no solo proporciona una distribución flexible de la funcionalidad en el software, sino que también facilita la distribución del trabajo entre los desarrolladores.

¿Qué es el tiempo real?

Anteriormente, escribí que muchas aplicaciones integradas funcionan en tiempo real. En este contexto, es costumbre hablar de sistemas operativos en tiempo real y no de un sistema operativo simple. Definamos la terminología.

“Un sistema operativo en tiempo real es un sistema en el que la exactitud de los cálculos depende no solo de la corrección lógica de los cálculos, sino también del tiempo durante el cual se logrará el resultado.

Si no se cumplen las limitaciones de tiempo del sistema, se cree que se ha producido una falla del sistema ".

Una característica importante de dicho sistema es su previsibilidad o, como se suele decir, el determinismo.

Un sistema operativo en tiempo real no es necesariamente muy rápido; "tiempo real" no siempre significa "tiempo realmente rápido". Esto significa que cualquier acción necesaria se completará de manera oportuna. Es decir, lo suficientemente rápido, pero al mismo tiempo no demasiado rápido (es decir, lo suficientemente lento).

RTOS (cuando se usa correctamente) proporciona un control muy preciso sobre la distribución del tiempo del procesador para las tareas y, por lo tanto, hace que las aplicaciones sean completamente deterministas. Lo único que puede arruinar esta imagen son las interrupciones. Hay RTOS que controlan completamente las interrupciones. Su trabajo es administrar el servicio de interrupción como parte del programador de tareas. A pesar de que esto debería conducir a un comportamiento predecible, este mecanismo es bastante complicado y contiene altos costos generales.

La mayoría de los RTOS simplemente permiten que el controlador de interrupciones "robe" el tiempo de una tarea que se estaba ejecutando en el momento de la interrupción. Esto, a su vez, obliga al programador a escribir el código del controlador de interrupciones lo más breve posible. Como resultado, tenemos un error permitido en tiempo real. La única dificultad es hacer llamadas a los servicios RTOS como parte de una tarea de controlador. Algunas llamadas pueden ser bastante inofensivas, mientras que otras causarán un cambio de contexto al regresar de una interrupción. Esta situación debe abordarse especialmente, lo cual es posible con la ayuda de varios RTOS.

Fuente: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

Cuando trabajamos en nuestro propio sistema operativo OSRV MAX en tiempo real (artículos publicados anteriormente sobre él) , nuestro equipo "encontró" el blog de Colin Walls, un experto en microelectrónica y firmware en Mentor Graphics. Los artículos parecían interesantes, los tradujeron por sí mismos, pero para no "escribir en la mesa" decidieron publicar. Espero que también te sean útiles. Si es así, entonces planeamos publicar todos los artículos traducidos en la serie.

Sobre el autor: Colin Walls ha trabajado en la industria electrónica durante más de treinta años, dedicando la mayor parte de su tiempo al firmware. Ahora es ingeniero de firmware en Mentor Embedded (una división de Mentor Graphics). Colin Walls a menudo habla en conferencias y seminarios, autor de numerosos artículos técnicos y dos libros sobre firmware. Vive en el Reino Unido. Blog profesional de Colin: http://blogs.mentor.com/colinwalls , correo electrónico: colin_walls@mentor.com

El artículo 3 se publica aquí.