Tasa de datos Rx en el bus CAN más rápida que la tasa de sondeo

Debe evitar las interrupciones cuando sea posible. Asuntos:

1. Confunden el comportamiento predecible en tiempo real.
2. Numerosas interrupciones pueden dar lugar a un uso imprevisto de la pila.
3. Es fácil escribir errores muy sutiles y muy graves al compartir datos entre un ISR y el programa en segundo plano.

Dicho esto, puede evitar estos problemas con un diseño cuidadoso del sistema.

1) es solo un problema para las interrupciones no cíclicas que pueden llegar en cualquier momento. Siempre que las interrupciones tengan un comportamiento determinista y se activen cíclicamente, puede utilizarlas. En ese caso, no son diferentes a un proceso de alta prioridad y aún puede predecir el comportamiento del sistema en tiempo real.

2) se puede evitar reduciendo el número de fuentes de interrupción en la medida de lo posible. Otras medidas de seguridad son asignar siempre una pila que sea más grande de lo necesario, y lo más importante: coloque la pila de modo que, al desbordarse, no falle en cascada en otros segmentos de memoria RAM como .bss o .data. Aquí hay un buen artículo sobre esto .

3) es el más difícil de protegerse. Cada variable compartida entre un ISR y el programa de fondo debe manejarse con mucho cuidado. Existen dos problemas: problemas de reingreso y optimizador del compilador.

El reingreso debe resolverse caso por caso con acceso atómico/semáforos/mutex o deshabilitando temporalmente las interrupciones. Esto siempre es complicado y debe asegurarse de haber considerado todos los escenarios y de que el código de máquina producido realmente haga lo que piensa.

El otro problema es que su compilador no se da cuenta de que la MCU llama a su ISR en lugar de su código y, por lo tanto, no comprende que todas las variables utilizadas por el ISR se pueden actualizar en cualquier momento. El compilador puede entonces optimizar el código de fondo incorrectamente, ya que asume que una determinada variable nunca se usa. Este error se puede evitar declarando siempre las variables compartidas con un ISR como volatile.

Ambos problemas son fuentes comunes de errores muy sutiles, pero a menudo graves. No hay una forma estándar de protegerse contra ellos, lo más parecido a una medida de seguridad es permitir que su veterano C más endurecido escriba todos los ISR. Los programadores con experiencia intermedia, sin mencionar los principiantes, siempre escriben estos errores, una y otra vez.

Debido a esto, es muy difícil justificar el uso de interrupciones en aplicaciones críticas para la seguridad. Tendría que dedicar mucho tiempo al diseño, las pruebas y la documentación para verificar que cada una de esas interrupciones no esté causando problemas. Por lo tanto, puedo entender por qué algunos estándares de seguridad prohíben por completo el uso de interrupciones.

En cuanto al problema específico de CAN, parece un poco que ha elegido la MCU incorrecta para la tarea o que no está utilizando el controlador CAN correctamente. Los controladores CAN más avanzados tienen búferes rx que puede configurar para mensajes dedicados y, además, un FIFO rx donde van el resto de los mensajes. Estoy bastante seguro de que NXP tiene tales controladores CAN para sus familias Cortex-M, al menos los tienen en LPC11C.

Con tal enfoque y un protocolo CAN de capa de aplicación cuidadosamente diseñado, no debería necesitar interrupciones rx. Todas las redes CAN críticas para la seguridad deben estar diseñadas para enviar mensajes una y otra vez periódicamente. Si sabe que un determinado mensaje solo llega una vez cada 5 ms, simplemente debe asegurarse de que su programa en segundo plano sea lo suficientemente rápido para manejarlo antes de que llegue el siguiente mensaje.

Para SIL4, probablemente tendría más de un bus CAN: dedicaría un bus para mensajes en tiempo real críticos para la seguridad y pondría todo lo demás en otro bus no crítico. A veces también se utilizan soluciones de redundancia con varios buses CAN que transmiten los mismos datos críticos.