CAN -> acceptance filter then interrupt or vice versa

Question

I would like to know which occurs first while using CAN communication. Based on the answer I would conclude whether an acceptance filter must be used in my project or not.

Scenario: There are three nodes in my project (for example, node A, B, and C). All have unique IDs. All nodes have been configured to interrupt on receiving a message. As of now, an acceptance filter is not configured for the nodes.

When node A sends a message to node B via CAN, both node B and C will trigger an Rx interrupt. In the ISR, I'll filter out the message based on ID in software. Suppose acceptance filters are configured for all the nodes, when node A again sends to node B, will even node C's Rx interrupt trigger?

My question is: Will a receive interrupt be triggered only after a message passes through the acceptance filter or is it triggered when a message is received by the CAN hardware even if an acceptance filter has been configured?

Note: I'm using LPC1778 (if that matters).

Answer 1

First the ID is checked and only then the data is put in the RX Fifo. Since you get an interrupt only when there is something in the RX fifo the interrupt will not occur. In the datasheet it will also be mentioned on how the acceptance filter works and how the data is captured. I also had a look at my microcontroller (ZYNQ 7000) which has a can in it and it says the exact same thing I have mentioned above. And this will not differ from microcontroller to microcontroller as CAN is a protocol and is uniform everywhere.

In page 568 from the same reference manual that I have shared below, it explains the type of interrupts that are possible in CAN. For example there is RxFIFO Not Empty interrupt, RxFIFO overflow interrupt, RxFIFO underflow (error) interrupt and the Message Rx interrupt. so if these interrupts are enabled in the interrupt enable register (pg 810) and if these bits are set in the interrupt status register (pg 807) then it goes inside the interrupt handler. The main interrupt for your case is the message RX interrupt which is triggered whenever a message is received, so if you enable this interrupt(which is needed if you want an interrupt whenever something is received and put in the RX fifo) then if your acceptance filter is configured to a particular message ID then only when this particular ID is received the message is put in the RXFIFO thereby causing an interrupt. So if this ID is not received then the RX message recieved interrupt flag will not be set in the interrupt status register and therefore the receive interrupt will not be triggered.

Answer 2

First, nodes don't have IDs, only messages do.

Second, using filters and masks is always optional. Their intent is to reduce firmware load by not bothering the firmware with message that you know up front are not relevant to that device.

I have done a number of CAN implementations, and have yet to use filters and masks. I can see how they would be useful in highly targeted devices where low power is important. However, they make good software architecture difficult. The decision of what messages to ignore should not really be done in the low level packet reception layer. That should be done at higher levels that understand the protocol used above CAN, not the bare CAN protocol. So far in the CAN projects I've had, it's been more trouble to generalize the finite number of masks and filters to arbitrary message acceptance criteria than any benefit gained.

I have my low level CAN reception layer receive whole packets and make them available to the application layer. The application layer then decides what to do with them, which could be nothing. This decision of how to process particular messages is usually done via a dispatch table, so ignoring messages simply means not including table entries for them. This mechanism is there anyway. So far the little extra processing power that requires hasn't been worth the less maintainable architecture of discarding messages at the low level in hardware.