2010-01-06 7 views
5

¿Cuál es el intervalo más corto en el que RT Linux puede ejecutar una tarea periódica (en tiempo real)?Tareas periódicas rápidas en RT Linux

Estoy investigando soluciones de hardware frente a software para una aplicación de adquisición de datos científicos. Los requisitos incluyen control de realimentación en tiempo real de procesos fisiológicos a aproximadamente 40 kHz. Hay soluciones de hardware (usando chips DSP programables), pero tengo curiosidad de saber si una tarea Linux en tiempo real podría manejar todo el problema. La tarea es simple: leer una muestra de la placa A/D, realizar aritmética simple y escribir una muestra en la placa A/D. ¿Puede RT Linux programar esta tarea 40 veces por segundo o es una velocidad irrazonable?

Si podemos realizar la tarea periódica en la CPU, podemos escribir la aplicación sin una dependencia de hardware. Si no, tendremos que usar un sistema híbrido de CPU/DSP. Obviamente, estoy esperando lo primero.

Respuesta

2

De acuerdo con http://www.ibm.com/developerworks/linux/library/l-real-time-linux/, incluso el linux no RT en un procesador decente puede ofrecer un intervalo de temporizador de 20μs en promedio, que corresponde a 50kHz. El mismo artículo menciona que los temporizadores de alta resolución en 2.6 kernel w/algunos mod RT pueden entregar intervalos de 1μs, o 1000kHz. Así que no creo que no sea razonable esperar que un kernel RT pueda entregar 40kHz confiablemente.

+1

non-RT linux puede entregar fácilmente * en promedio * 50kHz, pero los requisitos para este sistema son el peor de los casos 40kHz, por lo que no se usa RT-linux. La resolución del temporizador no garantiza que pueda disparar periódicamente a una velocidad determinada; Es posible que pueda hacer que un temporizador se dispare periódicamente a exactamente 232 μs, pero que 20 μs es demasiado rápido. –

+1

Sí ... mi punto es que si un no-RT puede entregar 50k * en promedio * (debido a que algunos intervalos se anulan, lo que resulta en un retraso), entonces un sistema de RT debería ser capaz de entregar 40k * de manera confiable *. No estoy sugiriendo que use no RT, simplemente utilizándolo como una comparación de "peor caso". –

Cuestiones relacionadas