operating-system - trenes - sistemas operativos en tiempo real pdf
¿Cómo funcionan los sistemas operativos en tiempo real? (12)
Básicamente, debe codificar cada "tarea" en el RTOS para que finalicen en un tiempo finito.
Además, su kernel asignaría cantidades específicas de tiempo a cada tarea, en un intento de garantizar que ciertas cosas sucedieran en ciertos momentos.
Tenga en cuenta que esta 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.
Me refiero a cómo y por qué los sistemas operativos en tiempo real pueden 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?
Lo que es importante 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.
Sucede que RTOS ayuda a hacer este trabajo (compilando la aplicación y verificando sus restricciones 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.
No es que puedan cumplir 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, por lo general, 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.
No he usado un RTOS, pero creo que así es como funcionan.
Hay una diferencia entre "tiempo real difícil" y "tiempo real suave". Puede escribir aplicaciones en tiempo real en un sistema no RTOS como Windows, pero son ''blandos'' en tiempo real:
Como aplicación, podría tener un hilo o un temporizador que le pida a la O / S que se ejecute 10 veces por segundo ... y tal vez el O / S lo haga, la mayoría de las veces, pero no hay garantía de que siempre lo haga. 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 utilizar para solicitar una garantía de que me ejecutarán en determinados momentos.Un O / S "difícil" en tiempo real (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.
Su RTOS está diseñado de tal manera que puede garantizar tiempos para eventos importantes, como el manejo de interrupciones de hardware y el despertar de los procesos de suspensión exactamente cuando deben estarlo.
Este tiempo exacto le permite al programador estar seguro 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 o Windows completamente desarrollado, simplemente porque es más fácil analizar y predecir el comportamiento del 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, no podrá garantizar sus tiempos hasta una escala tan pequeña como la de un sistema operativo más pequeño.
El planificador de RTOS también es más estricto que un planificador de propósito general. Es importante saber que el planificador no va a cambiar la prioridad de su tarea porque ha estado funcionando durante mucho tiempo y no tiene usuarios interactivos. La mayoría de los sistemas operativos reducirían la prioridad interna de este tipo de procesos para favorecer los programas interactivos a corto plazo en los que la interfaz no debería demorarse.
Puede que le resulte útil leer la fuente de un RTOS típico. Hay varios ejemplos de código abierto, y los siguientes arrojaron enlaces en un poco de búsqueda rápida:
Un RTOS comercial que está bien documentado, disponible en forma de código fuente y fácil de usar 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 utilizando la implementación real como código de ejemplo. El libro es MicroC OS II: The Real Time Kernel de Jean Labrosse.
He usado μC / OS-II en varios proyectos a lo largo de los años, y puedo recomendarlo.
... bien ...
Un sistema operativo en tiempo real intenta ser determinista y cumplir los plazos, pero todo depende de la forma en que escriba 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) determinismo del evento
Para cada conjunto de entradas se conocen los siguientes estados y salidas de un sistema
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 interrupciones, su sistema, en términos estrictos, ya no es determinista en el tiempo. (y la mayoría de los sistemas usan interrupciones)
Si realmente quieres ser determinista, sondea todo.
... pero tal vez no sea necesario ser 100% determinista
En realidad, no garantizan el cumplimiento de los plazos; Lo que hacen que los convierte en verdaderos RTOS es proporcionar los medios para reconocer y lidiar con los excesos 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.
La respuesta del libro de texto / entrevista es "prioridad preventiva". 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).
"Básicamente, debe codificar cada" tarea "en el RTOS de manera 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 conocida de tiempo (en milisegundos) en la que el pre-buffer se vaciará para cualquier tarea que esté procesando los datos. Por lo tanto, el uso de RTOS requiere un 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 que se conoce 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 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).
Ejemplos de diagramas de tiempo para el diseño de una aplicación de red de sistema operativo en tiempo real se encuentran en este artículo en EE Times, CÓMO HACER LOS PRODUCTOS: Mejorar la calidad de voz en tiempo real en un diseño de telefonía basado en VoIP http://www.eetimes.com/ diseño / embedded / 4007619 / PRODUCT-HOW-TO-Mejora-en-tiempo-voz-calidad-en-un-servicio de telefonía basado en VoIP
En RTOSes, los parámetros más críticos que se deben tener en cuenta son las latencias más bajas y el determinismo del tiempo. 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 mucho más livianas que los procesos / hilos en GPOS.
Cumplir con 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.
También 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 que proporciona un RTOS:
- Programador basado en prioridades
- Rutina de interrupción del reloj del sistema
- Comportamiento determinista
Programador basado en prioridades
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 abandona la CPU, se ejecuta la siguiente tarea de mayor prioridad, y así sucesivamente ...
La tarea de mayor prioridad en el sistema tendrá la CPU hasta que:
- se ejecuta hasta su finalización (es decir, renuncia voluntariamente a la CPU)
- se prepara una tarea de mayor prioridad, en cuyo caso la nueva tarea (de mayor prioridad) se adelanta a la tarea original.
Como desarrollador, es su trabajo asignar las prioridades de la tarea para que se cumplan sus plazos.
Rutinas de interrupción del reloj del sistema
El RTOS generalmente proporcionará algún tipo de reloj del sistema (entre 500 uS y 100 ms) 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 el simple hecho de 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 determinista
El RTOS hace todo lo posible para garantizar que, ya sea que tenga 10 tareas o 100 tareas, no le tome más tiempo cambiar el contexto, determinar cuál es la siguiente tarea de mayor prioridad, 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.
Esta es una generalización general y, como con todo lo demás, existe 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.