Me refiero a cómo y por qué los sistemas operativos en tiempo real son capaces de cumplir los plazos sin perderlos. ¿O es solo un mito (que no se pierden fechas límite)? ¿En qué se diferencian de cualquier sistema operativo común y qué impide que un SO regular sea un RTOS?¿Cómo funcionan los sistemas operativos en tiempo real?
cumplimiento de los plazos es una función de la aplicación que escribe. El RTOS simplemente proporciona instalaciones que lo ayudan a cumplir con los plazos. También puede programar en "bare metal" (sin RTOS) en un gran bucle principal y cumplir sus plazos.
Además, tenga en cuenta que, a diferencia de un SO de propósito más general, un RTOS tiene un conjunto muy limitado de tareas y procesos en ejecución.
Algunas de las instalaciones de un RTOS proporcionar:
basada en prioridad Programador
La mayoría de los RTOS tienen entre 32 y 256 posibles prioridades para tareas/procesos individuales. El planificador ejecutará la tarea con la más alta prioridad. Cuando una tarea en ejecución renuncia a la CPU, la tarea siguiente prioridad más alta se ejecuta, y así sucesivamente ...
La tarea de mayor prioridad en el sistema tendrá la CPU hasta que:
Como desarrollador, es su trabajo asignar las prioridades de la tarea de modo que se cumplan sus plazos.
sistema de reloj de las rutinas de interrupción
El RTOS proporciona en general una especie de reloj del sistema (entre 500 y 100 ms de Estados Unidos para) que le permite realizar operaciones sensibles al tiempo. Si tiene un reloj de sistema de 1 ms y necesita hacer una tarea cada 50 ms, generalmente hay una API que le permite decir "En 50 ms, despiértame". En ese punto, la tarea estaría durmiendo hasta que el RTOS lo despierte.
Tenga en cuenta que simplemente despertarse no garantiza que se ejecutará exactamente en ese momento. Depende de la prioridad. Si una tarea con una prioridad más alta se está ejecutando actualmente, podría retrasarse.
comportamiento determinístico
El RTOS va a la gran longitud para asegurar que si usted tiene 10 tareas o 100 tareas, no se necesita más para cambiar el contexto, determinar cuál es la próxima tarea de mayor prioridad es, etc ...
En general, la operación RTOS intenta ser O (1).
Una de las principales áreas para el comportamiento determinista en un RTOS es el manejo de interrupciones. Cuando se señala una línea de interrupción, el RTOS cambia inmediatamente a la Rutina de servicio de interrupción correcta y maneja la interrupción sin demora (independientemente de la prioridad de cualquier tarea que se esté ejecutando actualmente).
Tenga en cuenta que la mayoría de los ISR específicos del hardware los escribirían los desarrolladores del proyecto. El RTOS ya podría proporcionar ISR para puertos serie, reloj de sistema, tal vez hardware de red, pero cualquier cosa especializada (señales de marcapasos, actuadores, etc.) no formaría parte del RTOS.
Esto es una generalización general y como con todo lo demás, hay una gran variedad de implementaciones de RTOS. Algunos RTOS hacen las cosas de manera diferente, pero la descripción anterior debe ser aplicable a una gran parte de los RTOS existentes.
"Esta tarea se ejecutará hasta su finalización" suena como Windows 3.1! ¿Entonces quieres decir que los RTOS no son preventivos? –
No, si usted es la prioridad más alta, se ejecuta hasta que se da por vencido voluntariamente, O una tarea de mayor prioridad que la que está lista, momento en el que la (vieja) alta prioridad se anula. Lo aclararé en el texto principal. ¡Gracias! – Benoit
No es que puedan cumplir con los plazos, sino que tienen plazos fijos, mientras que en un sistema operativo regular no existe dicho plazo.
En un sistema operativo normal, el planificador de tareas no es realmente estricto. Es decir, el procesador ejecutará tantas instrucciones por segundo, pero ocasionalmente puede que no lo haga. Por ejemplo, una tarea puede ser eliminada para permitir la ejecución de una de mayor prioridad (y puede ser por más tiempo). En RTOS, el procesador siempre ejecutará la misma cantidad de tareas.
Además, normalmente hay un límite de tiempo para completar tareas después de las cuales se informa una falla. Esto no ocurre en el sistema operativo normal.
Obviamente hay muchos más detalles para explicar, pero los anteriores son dos de los aspectos de diseño importantes que se utilizan en RTOS.
Básicamente, debe codificar cada "tarea" en los RTOS para que finalicen en un tiempo finito.
Además, su kernel asignaría cantidades de tiempo específicas para cada tarea, en un intento de garantizar que ciertas cosas ocurran en ciertos momentos.
Tenga en cuenta que esto no es una tarea fácil de hacer sin embargo. Imagine cosas como llamadas a funciones virtuales, en OO es muy difícil determinar estas cosas. Además, un RTOS debe codificarse cuidadosamente con respecto a la prioridad, puede requerir una tarea de alta prioridad para la CPU dentro de x milisegundos, lo cual puede ser difícil dependiendo de cómo funcione su programador.
"Básicamente, debe codificar cada" tarea "en los RTOS para que finalicen en un tiempo finito" - entonces es la aplicación que debe llamarse en tiempo real y no el sistema operativo. –
¿Qué sucede cuando una tarea se queda sin tiempo? –
la tarea se reemplaza por la fuerza y se reinicia en su siguiente segmento de tiempo. Un buen RTOS generaría un error o notificaría que esto había ocurrido. – Spence
Lo que importa son las aplicaciones en tiempo real, no el sistema operativo en tiempo real. Por lo general, las aplicaciones en tiempo real son predecibles: se han realizado muchas pruebas, inspecciones, análisis WCET, pruebas, ... que muestran que las fechas límite se cumplen en cualquier situación específica.
Ocurre que RTOSes ayuda a hacer este trabajo (construyendo la aplicación y verificando sus restricciones de RT). Pero he visto aplicaciones en tiempo real ejecutándose en Linux estándar, confiando más en la potencia del hardware que en el diseño del sistema operativo.
A RTOS hace garantías muy estrictas sobre cosas que son importantes, como tiempos de servicio de interrupción, latencia de conmutación de tareas, etc. Las aplicaciones en tiempo real NO son posibles sin un RTOS apropiado. –
Estoy hablando de lo que he visto. Y más que a menudo, los problemas en tiempo real se resuelven con enormes frecuencias de CPU y mucho margen de tiempo. – mouviciel
No he usado un RTOS, pero creo que así es como funcionan.
Hay una diferencia entre "tiempo real duro" y "tiempo real suave". Puede escribir aplicaciones en tiempo real en un no-RTOS como Windows, pero son 'blandos' en tiempo real:
Como una aplicación, puede ser que tenga un hilo o temporizador que le pido al O/S para ejecutar 10 veces por segundo ... y tal vez el O/S hará eso, la mayoría de las veces, pero no hay garantía de que siempre será capaz de ... esta falta de garantía es la razón por la cual se llama 'suave' . La razón por la cual el O/S podría no ser capaz es porque un hilo diferente podría estar manteniendo el sistema ocupado haciendo otra cosa. Como aplicación, puedo aumentar mi prioridad de subproceso a, por ejemplo, HIGH_PRIORITY_CLASS, pero incluso si hago esto, el O/S aún no tiene API que pueda usar para solicitar una garantía de que se ejecutará en determinados momentos.
Un O/S 'duro' en tiempo real (me imagino) tiene API que me permiten solicitar sectores de ejecución garantizados. La razón por la cual el RTOS puede hacer tales garantías es que está dispuesto a anular terminantemente los hilos que toman más tiempo de lo esperado/de lo que están permitidos.
No es solo programar: el sistema operativo debe asegurarse de que no entren cosas al azar como la recolección de basura o la desfragmentación del espacio de direcciones de memoria, para que sepa que malloc() siempre regresará sin demora, por lo que (por ejemplo) el avión el piloto automático está controlando no se bloqueará. –
Y supuestamente interrupciones de hardware también. – ChrisW
Su RTOS está diseñado de tal manera que se pueda garantizar tiempos para eventos importantes, como la gestión de interrupciones de hardware y despertar los procesos durmiendo exactamente cuando tienen que ser.
Este tiempo exacto le permite al programador asegurarse de que su (por ejemplo) marcapasos va a emitir un pulso exactamente cuando lo necesita, no unas pocas decenas de milisegundos más tarde porque el sistema operativo estaba ocupado con otra tarea ineficiente.
Por lo general es un sistema operativo mucho más simple que un Linux de pleno derecho o Windows, simplemente porque es más fácil de analizar y predecir el comportamiento de código simple. No hay nada que detenga un SO completo como Linux en un entorno RTOS, y tiene extensiones RTOS. Debido a la complejidad de la base de código que no será capaz de garantizar a sus horarios a tan pequeña escala como un sistema operativo más pequeño.
El RTOS planificador también es más estricta que un planificador de propósito general. Es importante saber que el planificador no va a cambiar la prioridad de la tarea, ya que ha estado funcionando desde hace mucho tiempo y no tiene ningún usuarios interactivos. La mayoría de los OS reducirían interna la prioridad de este tipo de proceso para favorecer programas interactivos de corta duración en la interfaz no debe ser vista a la zaga.
Puede que le resulte útil leer la fuente de un RTOS típico. Hay varios ejemplos de código abierto por ahí, y los siguientes enlaces cedido en un poco de búsqueda rápida:
A RTOS comerciales que está bien documentado, disponible en forma de código fuente, y fácil de trabajar es µC/OS-II. Tiene una licencia muy permisiva para el uso educativo, y (una versión levemente desactualizada) de su fuente se puede vincular a un libro que describe su teoría de la operación usando la implementación real como código de ejemplo. El libro es MicroC OS II: The Real Time Kernel por Jean Labrosse.
He usado μC/OS-II en varios proyectos a lo largo de los años, y puedo recomendarlo.
... bueno ...
Un sistema operativo en tiempo real trata de ser determinista y cumplir los plazos, pero todo depende de la forma en que escribe su aplicación. Puede hacer un RTOS muy no en tiempo real si no sabe cómo escribir el código "correcto".
Incluso si sabes cómo escribir el código correcto: Se trata más de tratar de ser determinista que ser rápido.
Cuando hablamos de determinismo es
1) evento determinismo
Para cada conjunto de entradas de los siguientes estados y salidas de un sistema se conocen
2) determinismo temporal
... también se conoce el tiempo de respuesta para cada conjunto de salidas
Esto significa que si tiene eventos asincrónicos como yo nterrupts su sistema es estrictamente hablando ya no más determinista del tiempo. (y la mayoría de los sistemas usan interrupciones)
Si realmente quieres ser determinista, sondea todo.
... pero tal vez no es necesario ser 100% determinista
"Si realmente quieres ser determinista, encuestar todo". - ¿Qué pasa si se pierde un evento de mayor prioridad entre los ciclos de encuesta? ¿Esto no hará que la respuesta del sistema operativo no sea en tiempo real para esos eventos? –
Por supuesto que sí, pero usted hizo su análisis y se aseguró de que todos los eventos desde fuera del sistema operativo se realicen dentro de ciertos límites de tiempo (algo así como un servidor esporádico para sus entradas). En una condición de falla (cable agrietado), debe descartar los eventos de todos modos. Lo que aseguran al sondear y no usar interrupciones es que el hecho de que usen interrupción ya no es un determinismo degradante. –
¿Estás tratando de decir que esto es efectivamente una compensación entre la latencia y el determinismo? IMO, el modelo de "eventos en límites bien definidos" falla cuando tiene una jerarquía de eventos (es decir, eventos priorizados). No hay ninguna razón por la cual un evento totalmente no relacionado deba respetar los límites de tiempo de un evento/tarea de baja prioridad (LP). La tarea LP debe tener prioridad, incluso si el evento HP ocurre en t0 + dt. Donde dt es un período infinitesimalmente pequeño y t0 es el momento en que comenzó la tarea LP. –
La respuesta de libros de texto/entrevista es "determinista de tanteo". Se garantiza que el sistema transfiera el control dentro de un período de tiempo limitado si un proceso de prioridad más alta está listo para ejecutarse (en la cola lista) o si se establece una interrupción (normalmente entrada externa a la CPU/MCU).
En realidad, no garantizan los plazos de reunión; Lo que hacen que los convierte verdaderamente en RTOS es proporcionar los medios para reconocer y lidiar con los sobrepasos de los plazos. Los sistemas de RT "duros" generalmente son aquellos en los que falta un plazo es desastroso y se requiere algún tipo de parada, mientras que un sistema de RT "suave" es aquel en el que tiene sentido continuar con la funcionalidad degradada. De cualquier forma, un RTOS le permite definir las respuestas a dichos excesos. Los sistemas operativos que no son RT ni siquiera detectan excesos.
"Básicamente, debe codificar cada" tarea "en los RTOS para que finalicen en un tiempo finito."
Esto es realmente correcto. El RTOS tendrá un tic del sistema definido por la arquitectura, digamos 10 milisegundos, con todas las tareas (hilos) tanto diseñadas como medidas para completar en tiempos específicos. Por ejemplo, en el procesamiento de datos de audio en tiempo real, donde la frecuencia de muestreo de audio es de 48 kHz, existe una cantidad de tiempo conocida (en milisegundos) en la que el preajuste se vaciará para cualquier tarea en sentido descendente que esté procesando los datos. Por lo tanto, el uso de RTOS requiere el dimensionamiento correcto de los buffers, la estimación y medición de cuánto tiempo lleva esto y la medición de las latencias entre todas las capas de software del sistema. Entonces los plazos se pueden cumplir. De lo contrario, las aplicaciones perderán los plazos. Esto requiere un análisis del peor procesamiento de datos en toda la pila y, una vez conocido el peor de los casos, el sistema puede diseñarse para, por ejemplo, un 95% de tiempo de procesamiento con un 5% de tiempo de inactividad (este procesamiento puede no ocurrir nunca en cualquier uso real, porque el peor procesamiento de datos puede no ser un estado permitido dentro de todas las capas en un momento dado).
Ejemplo diagramas de tiempo para el diseño de una aplicación de red del sistema operativo en tiempo real están en este artículo en EE Times, PRODUCTO Cómo hacer: Mejora de la calidad de voz en tiempo real en un diseño de telefonía basada en VoIP http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
En RTOSes, los parámetros más importantes que se deben tener en cuenta son la latencia y el tiempo de determinismo más bajos. Lo cual hace agradablemente siguiendo ciertas políticas y trucos.
Mientras que en GPOSes, junto con las latencias aceptables, los parámetros críticos son de alto rendimiento. no puede contar con GPOS para determinar el tiempo.
Los RTOS tienen tareas que son mucho más livianas que los procesos/subprocesos en GPOS.
También es importante notar la diferencia entre un sistema en tiempo real suave y un sistema en tiempo real "difícil". – Thomas