Proteja la sección crítica del espacio del usuario de la interrupción

Estoy usando Beagle Bone Black con Arch Linux ARM OS para comunicarme con el chip ltc-6804 a través del puerto SPI. Llegué a un punto en el que la interrupción del sistema operativo en medio del envío del comando de lectura y la recepción de los valores medidos me causó problemas para obtener una medición válida del chip. ¿Hay alguna forma de "proteger" la parte del código que se interrumpe durante la ejecución? En otras palabras, deje que la sección de envío y lectura se complete sin ninguna interrupción.

Mueva el código de tiempo crítico a un controlador del sistema operativo, luego puede habilitar/deshabilitar las interrupciones.
Se agradecerá mucho un ejemplo detallado o material de lectura/sitio web. Este es mi primer proyecto relacionado con Linux.
Solo voy a comprar ese libro. He leído el enlace antes de publicar aquí, la respuesta parece que no es posible lograr lo que quiero.

Respuestas (4)

Este es un enfoque diferente a su problema, y ​​no se trata de trabajar dentro de Linux. En cambio, se trata de usar otros recursos de BeagleBone Black para resolver el problema.

Además del ARM Corex-A8, el BeagleBone Black también tiene dos procesadores más, llamados subsistema de unidad programable en tiempo real y subsistema de comunicación industrial (PRU-ICSS), a menudo solo PRU.

Las dos PRU se ejecutan independientemente del ARM que ejecuta Linux y, por lo tanto, no se ven afectadas por la programación de Linux; no serán interrumpidos ni reemplazados por Linux.

Las PRU están diseñadas para el procesamiento en tiempo real y tienen acceso a todas las E/S. Son núcleos RISC, cada uno de los cuales funciona a 200 MHz, por lo que deberían ser lo suficientemente rápidos y capaces de hacer todo lo que necesites. Podría dedicar uno a su tarea de comunicación SPI.

Se pueden programar en C o ensamblador. Hay varios artículos útiles en la web, este en Hackspace tiene enlaces útiles a ejemplos clave y tecnología. IIRC hay ejemplos que muestran cómo el 'procesador Linux' principal interactúa con una PRU.

Editar:
Este es un curso sobre el uso de la PRU .

Esto suena prometedor, lo investigaré.
@danteDev: si realiza una búsqueda utilizando términos como BeagleBone y PRU o PRI-ICSS, aparecerán varios enlaces de aspecto útil. El artículo de Hackspace parecía tener un montón de útiles y un buen lugar para comenzar. Los primeros artículos trataban sobre el uso del ensamblador PRU, que parecía factible pero arduo. Sin embargo, cuando TI lanzó el compilador C, todo parecía mucho más útil.

Estás buscando la solución equivocada al problema. Arregle el software correctamente en su lugar.

SPI es completamente síncrono. Como eres el amo, eres el dueño del reloj. Con rutinas SPI diseñadas correctamente, no debería haber ningún daño en los ciclos de robo de interrupciones arbitrariamente. Todo lo que debería hacer es estirar el tiempo entre las transiciones, lo que no debería ser un problema.

El problema es que el esclavo caerá al modo de suspensión (5 milisegundos) si la interrupción se demora más que la cuenta regresiva del temporizador al modo de suspensión durante la interrupción. ¿Sigue siendo el mismo caso?
@dant: Ese es un esclavo extraño si realmente se duerme después de 5 ms con la selección de chip aún afirmada . 5 ms es un tiempo muy, muy largo para una interrupción. O tienes una estrategia de interrupción muy mal diseñada, o algo más está pasando. Esto huele más a un sistema operativo que no funciona en tiempo real que detiene uno de los muchos procesos por un tiempo, no a una interrupción que toma el terriblemente largo tiempo de 5 ms.
Sí, hay muchos procesos en curso y seguiré agregando más procesos en el progreso. ¿Es eso un problema? No toqué nada en la parte de "interrupción de diseño", por lo que una interrupción mal diseñada no parece relevante para el programa de espacio del usuario, ¿verdad? Desde el programa de espacio del usuario, solo envío el comando de lectura y leo el resultado del esclavo, tan simple como eso. Lo que está pasando en el medio, no tengo idea. Oh, tengo que enfatizar, este problema ocurre en raras ocasiones, aproximadamente 1 inválida de cada 10000 lecturas. Quiero averiguar y resolver este problema.

Ninguna interrupción debería tomar 5 ms, eso es para siempre....

Sin embargo, es posible que se le esté adelantando, en cuyo caso puede considerar usar uno de los programadores posix en tiempo real en lugar del predeterminado, consulte las páginas de manual de sched_setscheduler para obtener más detalles.

Sin embargo, esto es mucho más una cuestión de software que de hardware.

Saludos, Dan.

No es broma, he observado más de 10 ms en alguna ocasión, pero no más de 15 ms. ¿Apropiarse e interrumpir no son lo mismo? Diríjame al enlace adecuado si esto no es adecuado para ser publicado aquí. Sin embargo, tendré una lectura en el "sched_setscheduler".

Si sucede con poca frecuencia, establezca una bandera en la rutina de interrupción que es inspeccionada por la rutina de lectura spi. Si está configurado, repita la operación de lectura después de borrar dicho indicador.

Sí, sucede en muy raras ocasiones, pero es muy crítico para la viabilidad del sistema. Se agradecerá mucho un ejemplo detallado o material de lectura/sitio web. Este es mi primer proyecto relacionado con Linux.
Proteja la sección crítica del espacio del usuario de la interrupción
RespuestasAquíPolítica de privacidad1y, 0v