CAN - filtro de aceptación luego interrumpir o viceversa

Primero se comprueba el ID y solo entonces se colocan los datos en el RX Fifo. Dado que solo recibe una interrupción cuando hay algo en el RX fifo, la interrupción no se producirá. En la hoja de datos también se mencionará cómo funciona el filtro de aceptación y cómo se capturan los datos. También eché un vistazo a mi microcontrolador (ZYNQ 7000) que tiene una lata y dice exactamente lo mismo que he mencionado anteriormente. Y esto no diferirá de un microcontrolador a otro, ya que CAN es un protocolo y es uniforme en todas partes.

En la página 568 del mismo manual de referencia que he compartido a continuación, explica el tipo de interrupciones que son posibles en CAN. Por ejemplo, hay una interrupción de RxFIFO No Vacío, una interrupción de desbordamiento de RxFIFO, una interrupción de subflujo (error) de RxFIFO y la interrupción de Rx de mensaje. por lo tanto, si estas interrupciones se habilitan en el registro de habilitación de interrupciones (pág. 810) y si estos bits se configuran en el registro de estado de interrupciones (pág. 807), se colocan dentro del controlador de interrupciones. La interrupción principal para su caso es el mensaje Interrupción de RX que se activa cada vez que se recibe un mensaje, por lo que si habilita esta interrupción (que es necesaria si desea una interrupción cada vez que se recibe algo y coloca el RX fifo), entonces, si acepta el filtro se configura para un ID de mensaje en particular, solo cuando se recibe este ID en particular, el mensaje se coloca en el RXFIFO causando una interrupción. Por lo tanto, si no se recibe este ID, el indicador de interrupción del mensaje de RX no se establecerá en el registro de estado de interrupción y, por lo tanto, la interrupción de recepción no se activará.

Primero, los nodos no tienen ID, solo los mensajes.

Segundo, el uso de filtros y máscaras es siempre opcional. Su intención es reducir la carga de firmware al no molestar al firmware con un mensaje que sabe que no es relevante para ese dispositivo.

He realizado varias implementaciones de CAN y aún no he usado filtros y máscaras. Puedo ver cómo serían útiles en dispositivos altamente específicos donde la baja potencia es importante. Sin embargo, hacen difícil una buena arquitectura de software. La decisión de qué mensajes ignorar no debería realizarse en la capa de recepción de paquetes de bajo nivel. Eso se debe hacer a niveles más altos que comprendan el protocolo utilizado anteriormente CAN, no el protocolo CAN simple. Hasta ahora, en los proyectos de CAN que he tenido, ha sido más problemático generalizar el número finito de máscaras y filtros a criterios de aceptación de mensajes arbitrarios que cualquier beneficio obtenido.

Tengo una capa de recepción CAN de bajo nivel para recibir paquetes completos y ponerlos a disposición de la capa de aplicación. La capa de aplicación decide qué hacer con ellos, lo que podría ser nada. Esta decisión de cómo procesar mensajes particulares generalmente se realiza a través de una tabla de envío, por lo que ignorar los mensajes simplemente significa no incluir entradas de tabla para ellos. Este mecanismo está ahí de todos modos. Hasta ahora, la poca potencia de procesamiento adicional que requiere no ha valido la pena por la arquitectura menos mantenible de descartar mensajes en el bajo nivel de hardware.