User Tag List

Resultados 1 al 5 de 5

Tema: Dudas sobre como trabajar con Linux Real Time

  1. #1

    Fecha de ingreso
    Sep 2005
    Ubicación
    Madri
    Mensajes
    438
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    13
    Agradecer Thanks Received 
    13
    Thanked in
    Agradecido 6 veces en [ARG:2 UNDEFINED] posts

    Dudas sobre como trabajar con Linux Real Time

    Buenas a todos,
    Una vez mas acudo a vosotros para que me iluminéis acerca de un tema del que tengo muy poca idea.

    En mi caso estoy usando una raspberry, pero el caso es general para cualquier linux (mas o menos).
    Tengo un kernel con rt_preempt habilitado pero desconozco la manera de poder usar esta funcionalidad en las aplicaciones que pueda crear. Entiendo que es la librería que gestiona un determinado puerto hardware quién debe reconocer que puede trabajar en timepo real, no sé si solo se puede conseguir compilando la librería con un flag de tiempo real.

    Ejemplo práctico:
    Dispositivo conectado a la raspberry a través del puerto SPI que usa una librería disponible en github para leer tarjetas inteligentes.
    ¿Como la librería se entiende con el rtos para ofrecerme tiempos "acotados"?
    ¿La librería tiene que estar creada específicamente para trabajar con tiempo real?

    Gracias por vuestro tiempo una vez mas.

  2. #2

    Fecha de ingreso
    Dec 2005
    Mensajes
    8,005
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    643
    Agradecer Thanks Received 
    635
    Thanked in
    Agradecido 410 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    52
    Cita Iniciado por crossmax Ver mensaje
    Buenas a todos,
    Una vez mas acudo a vosotros para que me iluminéis acerca de un tema del que tengo muy poca idea.

    En mi caso estoy usando una raspberry, pero el caso es general para cualquier linux (mas o menos).
    Tengo un kernel con rt_preempt habilitado pero desconozco la manera de poder usar esta funcionalidad en las aplicaciones que pueda crear. Entiendo que es la librería que gestiona un determinado puerto hardware quién debe reconocer que puede trabajar en timepo real, no sé si solo se puede conseguir compilando la librería con un flag de tiempo real.

    Ejemplo práctico:
    Dispositivo conectado a la raspberry a través del puerto SPI que usa una librería disponible en github para leer tarjetas inteligentes.
    ¿Como la librería se entiende con el rtos para ofrecerme tiempos "acotados"?
    ¿La librería tiene que estar creada específicamente para trabajar con tiempo real?

    Gracias por vuestro tiempo una vez mas.
    Hola.

    Que el kernel sea "preemtive" simplemente significa que un proceso puede ser expropiado de CPU incluso cuando está ejecutando código de kernel. Tradicionalmente cuando un proceso ejecuta una llamada al sistema no puede ser interrumpido, hasta que el mismo decida irse a dormir o el mismo quiera hacer una tarea I/O, momento en el que el sistema le manda a dormir y le vuelve a poner en la cola mientras ejecuta otros procesos.

    De esta manera los procesos que no son prioritarios porque no necesitan hacer llamadas al sistema pueden ejecutarse en un tiempo más predecible. En principio no necesitas hacer nada especial para trabajar en tiempo real con línux cuando tienes un kernel rt_preempt. Simplemente el sistama operativo sabe como despachar los procesos de manera más eficaz. Y esto de más eficaz va entre comillas. Antes de eso también era eficaz, en tanto en cuanto la CPU no está nunca ociosa con un proceso que está esperando a que termine una operación de I/O. Ahora simplemente es capaz de desalojar a un proceso gorrón que siempre está haciendo llamadas al sistema, especialmente largas.


    En tu cas concreto. SPI es un bus para periféricos que tiene un dispositivo maestro y uno o más dispositivos esclavos. Ahora mismo tendría que revisar como va el tema de quien inicia las comunicacines y esas cosas, pero básicamente cada vez que escuches el puerto o quieras leer de él tu proceso se irá a dormir, con o sin núcleo con capacidades de tiempo real. Y despertará cuando le toque, asumiendo que la operacón de entrada/salida haya terminado. y entonces tendrás tu dato, o lo que haya hecho tu dispositivo peroférico.

    En principio desde el Linux 2.6 (en estable) todos los kernel van de serie con "Preemtive" que a menos que se haya desactivado por una buena razón estará activado en el kernel de tu distrbución.
    A veces hago cosas

  3. #3

    Fecha de ingreso
    Sep 2005
    Ubicación
    Madri
    Mensajes
    438
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    13
    Agradecer Thanks Received 
    13
    Thanked in
    Agradecido 6 veces en [ARG:2 UNDEFINED] posts
    Muchas gracias por tu completísimo comentario. La verdad es que no había caído en que la gestión del SPI por parte del kernel será igual con parche RT o sin él. Yo pensaba que con un parche de este tipo podría establecer una prioridad a un proceso e, independientemente de si el proceso realiza tareas de I/O, mi proceso se antepondría a "casi" todas las tareas pendientes de realizar. Vaya chasco me he llevado entonces

    De todos modos, de lo que dices de los kernel de serie con "preemtive", hay algo que no me cuadra. Lo que he leído en el caso de la Raspberry, más concretamente de Raspbian, no encaja con que los últimos kernel vienen preparados (de la manera que yo busco) de serie. Estos son unos datos de un usuario que configura el kernel para tiempo real:

    Latencies for default Raspbian kernel (PREEMPT) in uS: Min: 00014 Avg: 00028 Max: 01247
    Latency results for PREEMPT_RT patched kernel in uS: Min: 00012 Avg: 00027 Max: 00077

    Por lo que deduzco que hay un preempt mas exclusivo aún que lo que comentas para tener un kernel lo más parecido a tiempo real.
    ¿Es posible que con está configuración, o con algún tipo de configuración similar, se consiga gestionar el SPI sin paradas del proceso por tareas de I/O?

    Muchas gracias de nuevo

  4. #4

    Fecha de ingreso
    Dec 2005
    Mensajes
    8,005
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    643
    Agradecer Thanks Received 
    635
    Thanked in
    Agradecido 410 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    52
    Cita Iniciado por crossmax Ver mensaje
    Muchas gracias por tu completísimo comentario. La verdad es que no había caído en que la gestión del SPI por parte del kernel será igual con parche RT o sin él. Yo pensaba que con un parche de este tipo podría establecer una prioridad a un proceso e, independientemente de si el proceso realiza tareas de I/O, mi proceso se antepondría a "casi" todas las tareas pendientes de realizar. Vaya chasco me he llevado entonces

    De todos modos, de lo que dices de los kernel de serie con "preemtive", hay algo que no me cuadra. Lo que he leído en el caso de la Raspberry, más concretamente de Raspbian, no encaja con que los últimos kernel vienen preparados (de la manera que yo busco) de serie. Estos son unos datos de un usuario que configura el kernel para tiempo real:

    Latencies for default Raspbian kernel (PREEMPT) in uS: Min: 00014 Avg: 00028 Max: 01247
    Latency results for PREEMPT_RT patched kernel in uS: Min: 00012 Avg: 00027 Max: 00077

    Por lo que deduzco que hay un preempt mas exclusivo aún que lo que comentas para tener un kernel lo más parecido a tiempo real.
    ¿Es posible que con está configuración, o con algún tipo de configuración similar, se consiga gestionar el SPI sin paradas del proceso por tareas de I/O?

    Muchas gracias de nuevo
    Con Raspberry Pi no tengo apenas experiencia. Tengo una model B en la que instalé Raspian y no he hecho nada con ella desde entonces. Para una asignatura de la universidad una vez escribí uan scheduller sencillo, pero ni por asomo se acerca al nivel e complejidad de un scheduller de un sistema operativo moderno. Premptive lo unico que hace es que el sistema parezca más interactivo o con mejor respuesta a la hroa de multitarea. Te recuerdo que un sólo procesador o core en realinado no hacen multitarea real sino que realizan time sharing. la CPU cambia continuamente entre procesos, cada vez que uno va a hacer una tarea que no depende de la CPU, como las costosas opeaciones de E/S esta lo manda a dormir y se ocupa de atende a otro).

    Desde fuera parece que está ejecutano todo a la vez, aunque es mentira. Obviamente con más CPU (o cores) el planificador del sistema operativo despacha tareas a todas las CPU, por lo que si hay multitarea real, pero sigue habiendo tiempo compartido si hay más tareas que núcleos de ejecución.

    Hay ciertas tareas que no son muy amigas del tiempo compartido porque hacen muchas llamadas al sistema o son muy pesadas (y que típicamente no se podían interrumpir hasta que finalizaban) y esto penalizaba a las demás tareas. Con preemtive "parece" que el sistema reacciona meor o tiene mejor interactividad, porque las CPU cambian de tarea en algunas ocasiones en las que sin esa característica no lo harían.

    Si las tareas que ese usuario quiere realizar requieren de llamadas al sistema continuas o estas son largas muy probablemente le penalice el preemtive, ya que esto solo ayuda a tareas menos prioritarias.

    De todas maneras si quieres cambiar la prioridad de un proceso tienes el comando renice para hacerlo (ojo, para arle a un proceso más prioridad que la que tiene por defecto hay que ser root). En caso de tareas de usuario nunca he encontrado útil dar prioridad a un proceso. En ciertas tareas de servidor si que lo he visto necesario, pero si hace ucha falta eso lo suelen hacer los programas servidores mediante llamadas al sistema que ya van en el código y a nivel de administración de sistemas no lo ves. Si hace falta aumentar prioridad para hacer malabares y poder ejecutar las tareas a tiempo es que hace tiempo que había que haber invertido en la adquisición de más hierro.

    -----Actualizado-----

    EDITO: No he contestado a tu pregunta. La doferencia entre preemtive y preemtive_rt es que mejora el peor caso. En ambos casos es tiempo real porque hace una esticación del máximo tiempo que un proceso va a tardar en ser espachado por la CPU, pero en el segundo caso la diferencia entre media, mínima y máxima es bastante más consistente, lo que en ese escenario concreto imagino que supone más expropiacines de CPU.
    A veces hago cosas

  5. #5

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,441
    Mencionado
    112 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    329
    Agradecer Thanks Received 
    1,183
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por crossmax Ver mensaje
    Buenas a todos,
    Una vez mas acudo a vosotros para que me iluminéis acerca de un tema del que tengo muy poca idea.

    En mi caso estoy usando una raspberry, pero el caso es general para cualquier linux (mas o menos).
    Tengo un kernel con rt_preempt habilitado pero desconozco la manera de poder usar esta funcionalidad en las aplicaciones que pueda crear. Entiendo que es la librería que gestiona un determinado puerto hardware quién debe reconocer que puede trabajar en timepo real, no sé si solo se puede conseguir compilando la librería con un flag de tiempo real.

    Ejemplo práctico:
    Dispositivo conectado a la raspberry a través del puerto SPI que usa una librería disponible en github para leer tarjetas inteligentes.
    ¿Como la librería se entiende con el rtos para ofrecerme tiempos "acotados"?
    ¿La librería tiene que estar creada específicamente para trabajar con tiempo real?

    Gracias por vuestro tiempo una vez mas.
    Recomendable es que compiles la función que utiliza el puerto SPI como atómica (código que se tiene que ejecutar sin poder ser interrumpido), dado que el dispositivo conectado no puede soportar que la señal de reloj del SPI se interrumpa y querer que después de esto la comunicación transcurra con normalidad.

    En un microcontrolador moderno (de 32 bits) se hace deshabilitando las interrupciones y el servicio de solicitudes pendientes (característica de los procesadores) al entrar en la parte atómica del código y habilitándolas de nuevo al salir, en un sistema operativo con interfaz de usuario y demás (Windows, Linux) se hace deshabilitando el servicio de solicitudes pendientes (de esta forma el sistema puede cascar con pantallazo azul o no, eso no hay casi manera de saberlo) o, como he llegado a hacer en Windows, incrustando tu código antes de la ejecución del kernel, con esto último obtienes Tiempo-Real de verdad, como en un microcontrolador, pero tienes que currarte una función pasarela para poder obtener información de los dispositivos que necesiten driver (en el kernel no existen los drivers típicos, es como el DOS; también puedes acceder directamente consultando direcciones de memoria que es lo que hacen las tarjetas hardware de adquisición de datos soportadas en Matlab y LabView) para funcionar, con lo que los datos llegarán siempre a tu programa en Tiempo-Real con una iteración de retraso.


    Además que lo realmente malo del SPI es que es un medio de comunicación serie (no es un bus, por mucho que lo diga Wikipedia u otros, los buses necesitan direcciones para cada dispositivo y poder intercambiar los roles / el testigo de quién es en ese momento el maestro de la comunicación) no bloqueante en el que no hay ningún mecanismo para saber si el dispositivo se ha desconectado o no de tu cableado, en estos casos lo normal es que si el dispositivo devuelve todo a 0 o todo a 1, se sobreentienda que se ha desconectado; muchos sensores no proporcionan valores todo 0 o todo 1 con este fin.

    Por eso, por norma general, en un sistema tipo PC o similar, Solaris, SPARC, PowerPC en lugar de emplear Windows o Linux con sus difíciles de utilizar posibilidades de Tiempo-Real, se emplean sistemas operativos con interfaz gráfica que manejan el sistema completo como si de un microcontrolador se tratase, como el sistema operativo VxWorks.

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •