¿Cómo "tiempo real" es Linux 2.6?

embedded real-time (4)

¿Has Xenomai un vistazo a Xenomai ? Le permitirá ejecutar procesos "duros en tiempo real" por encima de Linux, a la vez que le permitirá acceder a las API regulares de Linux para todas las necesidades en tiempo no real.

Estoy buscando mover mi producto de un RTOS a Linux integrado. No tengo muchos requisitos en tiempo real, y los pocos requisitos de RT que tengo son del orden de 10s de milisegundos.

¿Alguien puede indicarme una referencia que me diga en tiempo real la versión actual de Linux?

¿Hay alguna otra trampa de pasar a un RTOS comercial a Linux?

Hay dos enfoques fundamentalmente diferentes para lograr capacidades en tiempo real con Linux.

1) Parchea el kernel existente con cosas como los parches rt-preempt. Esto conducirá eventualmente a un núcleo totalmente preventivo.

2) Enfoque de doble núcleo (como xenomai, RTLinux, RTAI, ...)

Hay muchas trampas que se mueven de un RTOS a Linux.

Tal vez realmente no necesita en tiempo real?

Estoy hablando de Linux en tiempo real en mi entrenamiento: http://www.reliableembeddedsystems.com/embedded-systems_7.html

La respuesta es probablemente "lo suficientemente buena".

Si está ejecutando un sistema integrado, probablemente tenga el control de todo o la mayoría del software en la caja.

Stock Linux 2.6 tiene varias características adecuadas para tareas de baja latencia, principalmente estas son:

Políticas de programación
Bloqueo de memoria

Suponiendo que está utilizando una máquina de un solo núcleo, si tiene una sola tarea que ha establecido su política de programación en SCHED_FIFO o SCHED_RR (no importa cuál si es una sola tarea), Y bloqueó toda su memoria con mlockall (), entonces se programará tan pronto como esté listo para ejecutarse.

Entonces, de lo único de lo que tendría que preocuparse es si una parte no preferible del kernel tarda más que su latencia aceptable en completarse, lo cual es poco probable que ocurra en un sistema integrado a menos que suceda algo malo, como una presión extrema en la memoria, o sus conductores son poco fiables.

Supongo que "pruébelo y vea" es una buena respuesta, pero probablemente sea algo complicado en su caso (y puede implicar escribir controladores de dispositivos, etc.).

Mire el doc para sched_setscheduler para obtener una buena información.

Puede obtener la mayoría de sus respuestas en la wiki Real Time Linux y en las FAQ

¿Cuáles son las capacidades en tiempo real del kernel de linux stock 2.6?
Tradicionalmente, el kernel de Linux solo permitirá que un proceso se anule a otro solo bajo ciertas circunstancias:
Cuando la CPU está ejecutando código de modo de usuario
Cuando el código del kernel regresa de una llamada del sistema o una interrupción al espacio del usuario
Cuando el código del kernel bloquea un bloque en un mutex, o cede explícitamente el control a otro proceso
Si el código del kernel se está ejecutando cuando ocurre algún evento que requiere un subproceso de alta prioridad para comenzar a ejecutarse, el subproceso de alta prioridad no puede adelantarse al código del kernel en ejecución, hasta que el código del kernel ceda el control explícitamente. En el peor de los casos, la latencia podría ser de cientos de milisegundos o más.
La opción de configuración de Linux 2.6 CONFIG_PREEMPT_VOLUNTARY introduce las comprobaciones de las causas más comunes de las latencias largas, de modo que el kernel pueda ceder voluntariamente el control a una tarea de mayor prioridad en espera de ejecutarse. Esto puede ser útil, pero mientras reduce las ocurrencias de latencias largas (cientos de milisegundos a potencialmente segundos o más), no las elimina. Sin embargo, a diferencia de CONFIG_PREEMPT (que se describe a continuación), CONFIG_PREEMPT_VOLUNTARY tiene un impacto mucho menor en el rendimiento general del sistema. (Como siempre, hay un compromiso clásico entre el rendimiento, la eficiencia global del sistema, y la latencia. Con las CPU más rápidas de los sistemas modernos, a menudo tiene sentido cambiar el rendimiento por las latencias más bajas, pero el servidor Los sistemas de clase que no necesitan garantías de latencia mínima pueden muy bien optar por utilizar CONFIG_PREEMPT_VOLUNTARY, o para atenerse al diseño tradicional de kernel no preferible.)
El kernel 2.6 de Linux tiene una opción de configuración adicional, CONFIG_PREEMPT, que hace que todo el código del kernel fuera de las regiones protegidas por spinlock y los manejadores de interrupciones sean elegibles para la preferencia no voluntaria por parte de los hilos del kernel de mayor prioridad. Con esta opción, la latencia en el peor de los casos se reduce a milisegundos de un dígito (alrededor), aunque algunos controladores de dispositivos pueden tener controladores de interrupción que introducirán la latencia mucho peor que eso. Si una aplicación de Linux en tiempo real requiere latencias más pequeñas que milisegundos de un solo dígito, se recomienda el uso del parche CONFIG_PREEMPT_RT.

También tienen una lista de "Gotcha''s" como los llamaste en las Preguntas frecuentes.

¿Qué cosas importantes se deben tener en cuenta al escribir aplicaciones en tiempo real?
Cuidando lo siguiente durante la fase inicial de arranque:
Llame a mlockall () tan pronto como sea posible desde main ().
Cree todos los subprocesos en el momento de inicio de la aplicación y toque cada página de la pila completa de cada subproceso. Nunca inicie los subprocesos dinámicamente durante el tiempo de RT show, esto arruinará el comportamiento de RT.
Nunca use llamadas al sistema que se sabe que generan fallas de página, como fopen (). (La apertura de archivos realiza la llamada al sistema mmap (), que genera un error de página).
Si utiliza ''variables globales de tiempo de compilación'' y / o ''arreglos globales de tiempo de compilación'', entonces use mlockall () para evitar errores de página al acceder a ellos.
más información: HOWTO: Construir una aplicación RT

También tienen una gran página de publicaciones que es posible que desee retirar.